Audyt aplikacji React Native z Cursora: co sprawdzić przed launchem

Aplikacja z Cursora wygląda na prawie gotową, a każde kolejne zadanie przed launchem odsłania następną dziurę.

TL;DR

Audyt aplikacji React Native zbudowanej w Cursorze ma odpowiedzieć na jedno pytanie: czy da się doprowadzić ten kod do launchu szybciej, niż napisać krytyczną ścieżkę od nowa. Sprawdzasz fundament, wersję Expo albo React Native, stan zależności, nawigację, logowanie, logikę subskrypcji, analitykę, obsługę błędów, przepływ AI i gotowość na App Store. Typowy problem nie polega na tym, że Cursor napisał "zły kod". Problem w tym, że postęp prompt po prompcie tworzy decyzje, które nie trzymają się kupy. Jeśli główna ścieżka użytkownika jest czytelna, a build działa na urządzeniu, naprawiaj. Jeśli logowanie, płatności i stan są splątane, przepisz krytyczną ścieżkę, zanim wydasz kolejny tydzień na prompty.

Najważniejsze fakty

• Działający preview to nie to samo co działający build na TestFlight.

• Cursor daje najwięcej tam, gdzie architektura jest jasna, a zadania małe.

• Najpierw audytujesz ścieżkę do launchu: onboarding, logowanie, główna funkcja, paywall, analityka, ustawienia, usuwanie konta.

• Rozjechane wersje paczek i downgrade Expo to problemy fundamentu, nie kosmetyka.

• Ekran paywalla nie oznacza, że subskrypcje, restore purchases i entitlements działają.

• Naprawiaj istniejący kod, gdy główny flow da się prześledzić, a łańcuch buildów jest zdrowy.

• Przepisz krytyczną ścieżkę, gdy każdy ekran ma własny model stanu albo własną regułę płatności.

Diagnoza: co zwykle jest zepsute

Najmocniejszy kontrargument wobec "to już prawie gotowe" jest prosty: nikt nie przetestował tej aplikacji w warunkach launchu.

Cursor potrafi wygenerować ekrany, spiąć komponenty, wytłumaczyć błąd i szybko popchnąć projekt React Native do przodu. Ta szybkość jest realna. Audyt zaczyna się od odmowy mylenia widocznego postępu z gotowością produktu.

Otwórz repo i prześledź jedną ścieżkę użytkownika:

1. użytkownik otwiera aplikację

2. użytkownik zakłada konto albo wchodzi bez konta

3. użytkownik kończy onboarding

4. użytkownik dociera do głównej funkcji

5. użytkownik trafia na paywall albo limit darmowy

6. użytkownik płaci, robi restore albo wychodzi

7. użytkownik wraca po restarcie aplikacji

8. użytkownik może zarządzać kontem, prywatnością i je usunąć

Jeśli kod nie odpowiada czysto na te stany, aplikacja nie jest gotowa na użytkowników. Może dalej da się ją uratować, ale najpierw potrzebuje diagnozy, a nie kolejnych promptów o funkcje.

Pierwsza zepsuta warstwa to zwykle fundament. Sprawdź wersję Expo SDK albo React Native, lockfile, natywne moduły, skrypty buildu, konfigurację EAS, bundle identifier na iOS, nazwę pakietu na Androidzie i zmienne środowiskowe. Jeśli Cursor naprawił błąd zależności downgradem Expo albo doinstalowaniem drugiej biblioteki do tej samej roboty, aplikacja może działać lokalnie, a natywna ścieżka buildu i tak jest niestabilna.

Druga zepsuta warstwa to stan. Cursor rozwiązuje bieżący prompt. Efekt: stan logowania w jednym ekranie, stan onboardingu w drugim, stan subskrypcji w pliku z kontekstem, a dane użytkownika w local storage. Działa do momentu, w którym prawdziwy użytkownik się wyloguje, zrobi restore purchases, straci sieć albo wróci po wygaśnięciu sesji.

Trzecia zepsuta warstwa to przychód. Aplikacje generowane przez AI często mają paywall, który wygląda na skończony, ale niczego nie blokuje. Produkcyjny paywall potrzebuje produktów ze sklepu, obsługi błędów zakupu, restore purchases, sprawdzania entitlements, obsługi triala, obsługi wygasłej subskrypcji i analityki. Jeśli dostęp płatny zależy od lokalnego boola albo od kliknięcia w przycisk, przychód nie jest podpięty.

Czwarta zepsuta warstwa to gotowość na App Store. App Review nie interesuje, że demo wyglądało dobrze. Interesuje go usuwanie konta, polityka prywatności, adres wsparcia, informacja o subskrypcji, notatki dla recenzenta, konto testowe, opisy uprawnień, zachowanie przy crashu i to, czy aplikacja robi to, co obiecuje opis w sklepie.

Diagnoza ma dać zwykłą odpowiedź:

• co jest zepsute

• dlaczego tak się stało

• czy ten kod naprawiać

• co przepisać od nowa

• co blokuje TestFlight albo wysyłkę do App Store

To jest różnica między audytem a kolejną rundą debugowania.

Ścieżka naprawy: audyt, naprawa albo przepisanie

Zacznij od kodu, który steruje biznesem, a nie od najładniejszego ekranu.

Po pierwsze, udowodnij build. Uruchom aplikację na prawdziwym symulatorze albo urządzeniu, potem przejdź produkcyjną ścieżkę buildu. Przy projektach Expo oznacza to sprawdzenie konfiguracji EAS i zgodności natywnych zależności. Przy bare React Native sprawdzasz pody na iOS, Gradle na Androidzie, bundle identifiers, założenia dotyczące podpisywania i konfigurację natywnych uprawnień. Jeśli projekt nie potrafi wyprodukować powtarzalnego buildu, nie polerujesz UI.

Po drugie, zmapuj główną podróż. Wypisz maszynę stanów zwykłym językiem:

• wylogowany

• zalogowany

• onboarding niedokończony

• onboarding skończony

• darmowy

• w trialu

• płacący

• wygasły

• usunięty albo z żądaniem usunięcia

Jeśli tych stanów nie ma w kodzie, stwórz je, zanim dorzucisz kolejne funkcje. Jeśli istnieją w trzech różnych wersjach, scal je. To właśnie tutaj aplikacje z Cursora albo okazują się naprawialne, albo pokazują, że krytyczną ścieżkę trzeba napisać od nowa.

Po trzecie, zaudytuj integracje. Supabase, Firebase, RevenueCat, Stripe, OpenAI, Anthropic, analityka, crash reporting i push notyfikacje mają konfigurację poza widoczną aplikacją. Wygenerowany wrapper wokół wywołania API to nie to samo co produkcyjna integracja. Sprawdź klucze, środowiska, obsługę błędów, retry, własność danych po stronie użytkownika i to, co się dzieje, gdy dostawca padnie.

Po czwarte, obetnij zakres. Wiele projektów z Cursora ma połowę ekranów niedokończonych, bo narzędzie sprawia, że dodatkowy ekran jest tani. Wysyłka do sklepu nie robi się łatwiejsza od tego, że drzewo plików jest większe. Wybierz najmniejszą wersję, która obsłuży użytkowników, płatności, analitykę i App Review. Usuń albo ukryj wszystko, co nie wspiera tej ścieżki.

Zasada naprawa kontra przepisanie:

• Naprawiaj, jeśli build działa, główną podróż da się prześledzić, zależności są wystarczająco aktualne, a zły kod jest odizolowany.

• Przepisz krytyczną ścieżkę, jeśli logowanie, onboarding, płatności i nawigacja są ze sobą splątane.

• Przepisz fundament, jeśli Expo albo natywne zależności zostały wygięte tylko po to, żeby zniknął błąd.

• Zacznij od audytu, jeśli nie wiesz, w której kategorii jesteś.

Ratunek dla aplikacji w Silpho powstał dokładnie na ten moment: masz prototyp z Cursora, Lovable, Bolta, Replit albo podobnego narzędzia i potrzebujesz decyzji o launchu, a nie kolejnego ogólnego code review. Audyt ma powiedzieć, czy naprawiać istniejące repo, przepisać krytyczną ścieżkę, czy wejść w sprint launchowy.

Szerszą checklistę znajdziesz w tekście Cursor zbudował Twoją aplikację React Native? Jak dowieźć ją na produkcję.

Porównanie

FAQ

Czy Cursor wystarczy do zbudowania aplikacji React Native?

Tak, tylko trzeba szczerze zdefiniować "wystarczy". Cursor przyspiesza implementację, gdy architektura, stack i granice zadań są jasne. Nie udowodni gotowości na App Store tylko dlatego, że preview się uruchamia.

Co audyt aplikacji z Cursora powinien sprawdzić najpierw?

Główną ścieżkę do launchu, zanim pojedyncze pliki. Onboarding, logowanie, główna funkcja, paywall, analityka, ustawienia, usuwanie konta i zachowanie po restarcie znaczą więcej niż to, czy jeden komponent jest ładny. Jeśli ta ścieżka jest niejasna, aplikacja nie jest gotowa.

Kiedy przestać promptować Cursor i poprosić o przegląd?

Gdy każda poprawka rodzi nowego buga, gdy nie potrafisz opisać modelu stanu albo gdy aplikacja działa tylko na jednej szczęśliwej ścieżce. To objawy architektury. Kolejne prompty dalej pomogą, ale dopiero po ustaleniu planu naprawy.

Czy aplikacja z Cursora częściej wpada w odrzucenie w App Review?

Nie z powodu Cursora. Ryzyko polega na tym, że aplikacje budowane przez AI często pomijają usuwanie konta, szczegóły prywatności, informację o subskrypcji, restore purchases, konta testowe, adres wsparcia i stabilność na urządzeniu. App Review widzi te braki, a nie narzędzie, które napisało kod.

Jak poznać, czy naprawiać, czy pisać od nowa?

Naprawiaj, gdy projekt buduje się powtarzalnie, główny flow jest zrozumiały, a zepsute części są odizolowane. Przepisz krytyczną ścieżkę, gdy logowanie, płatności, nawigacja i stan użytkownika są rozsmarowane po ekranach. Przepisz fundament, gdy decyzje o zależnościach robią produkcyjne buildy kruchymi.

Czy audyt obejmuje płatności i RevenueCat?

Powinien. Audyt aplikacji mobilnej, który pomija logikę entitlements, jest niekompletny przy produkcie subskrypcyjnym. Sprawdza się identyfikatory produktów, flow zakupu, restore purchases, stany triala, wygasłych użytkowników, kontrolę dostępu i zdarzenia analityczne wokół paywalla.

Czy Kickstart pomoże, jeśli chcę dalej budować sam?

Tak. Kickstart pasuje lepiej, gdy chcesz boilerplate Ship React Native, sesję 1 na 1, code review i wsparcie, a build robisz sam. To nie jest sprint ratunkowy zrobiony za Ciebie.

Co, jeśli audyt powie, że aplikację trzeba napisać od nowa?

To użyteczna informacja, nie porażka. Przepisanie może zachować pomysł na produkt, markę, teksty, sensowne ekrany i zwalidowane decyzje, a wymienić ryzykowną ścieżkę do launchu. Drogi błąd to kolejny miesiąc ratowania kodu, który i tak nie powinien trafić do sklepu.

Następne kroki

• Zobacz cennik Silpho

• Zacznij od Ratunku dla aplikacji

• Przeczytaj przewodnik po dowożeniu aplikacji z Cursora na produkcję