Awaryjna naprawa błędu w React Native przed premierą: triage, naprawa czy przebudowa

Data premiery jest blisko, a build release wywala się przy starcie, logowanie gubi użytkowników albo paywall przyznaje zły dostęp.

Skrót

Awaria React Native przed premierą wymaga najpierw opanowania sytuacji, dopiero potem zmian w kodzie. Zamroź nowe funkcje, zachowaj wadliwy build i logi, odtwórz problem w tym samym środowisku release i przejdź jedną ścieżkę użytkownika od czystej instalacji do płatnego rezultatu. Napraw pojedynczy błąd, kiedy znasz jego właściciela, wyzwalacz i masz test regresji. Zrób audyt, gdy kilka systemów nie zgadza się co do logowania, nawigacji, płatności albo konfiguracji produkcyjnej. Przebuduj ścieżkę krytyczną, jeśli każda łatka rodzi kolejną awarię albo nikt nie umie wyjaśnić stanu wydania. Celem nie jest zielony preview. Celem jest stabilny build na TestFlight albo internal track, który przeżyje App Review i prawdziwych użytkowników.

Najważniejsze fakty

• Błąd, który pojawia się tylko na TestFlight, na Androidowym internal tracku albo w trybie release, trzeba odtworzyć dokładnie w tym środowisku.

• Expo Go i symulator potrafią ukryć konfigurację natywną, podpisywanie, produkcyjne sekrety i problemy z cyklem życia aplikacji.

• Logowanie idzie przed płatnościami, bo stan entitlements potrzebuje stabilnej tożsamości użytkownika.

• Udany zakup nadal jest zepsuty, jeśli dostęp znika po restarcie, logowaniu, restore purchases albo reinstalacji.

• Zasoby do App Store, odpowiedzi o prywatność, usuwanie konta, analityka i dostęp dla recenzenta to praca przed premierą, nie sprzątanie na później.

• Naprawiaj, kiedy awaria jest odizolowana, a fundament wydania da się wytłumaczyć.

• Przebuduj ścieżkę krytyczną, gdy zależności, własność stanu albo konfiguracja natywna nie dają się ustabilizować punktową naprawą.

Diagnoza: nazwij awarię, zanim dotkniesz kodu

"Aplikacja jest zepsuta" to nie jest zgłoszenie. Podaj build, urządzenie, stan konta, akcję i obserwowany rezultat.

Zacznij od jednego zdania opisującego awarię. Na przykład: "Na świeżej instalacji z TestFlight Sign in with Apple wraca na ekran logowania" albo "Zakup w sandboxie kończy się sukcesem, ale dostęp premium znika po restarcie aplikacji". Takie zdanie daje coś, co da się przetestować. "Coś jest nie tak z logowaniem" i "RevenueCat nie działa" zapraszają do losowych łatek.

Zabezpiecz dowody, zanim zmienisz zależności albo projekty natywne:

1. Zapisz commit i numer builda, który zawiódł.

2. Zachowaj pierwszy sensowny błąd, crash log, urządzenie, wersję systemu i stan konta.

3. Spisz dokładne kroki od świeżej instalacji do awarii.

4. Zanotuj zmienne produkcyjne, bundle ID, endpointy API, kanały aktualizacji i produkty w sklepie.

5. Ustal, czy awaria zdarza się przed startem JavaScriptu, w trakcie przywracania stanu aplikacji, czy po akcji użytkownika.

To ostatnie rozróżnienie decyduje o ścieżce naprawy. Crash przy starcie, jeszcze przed pierwszym widokiem Reacta, wskazuje na moduł natywny, bundle release albo konfigurację. Crash po tapnięciu przycisku siedzi zwykle w JavaScripcie, w odpowiedzi API albo w obsłudze stanu. Zakup, który przechodzi, a dostęp zostaje zablokowany, to prawie zawsze problem tożsamości albo stanu entitlements, nie problem projektu paywalla.

Potem rozpisz ścieżkę do premiery jako jedną sekwencję:

świeża instalacja -> onboarding -> logowanie -> główny rezultat -> paywall -> zakup -> entitlement -> restart -> restore -> usunięcie konta

Każdy krok oznacz jako sprawdzony, wadliwy albo nietestowany. Dopracowane ekrany niewiele znaczą, jeśli aplikacja nie umie utrzymać sesji, podnieść się po błędzie ani rozpoznać wracającego płacącego użytkownika.

Ścieżka naprawy: stabilizuj wydanie w kolejności zależności

Zamroź pracę nad funkcjami. Gałąź awaryjna powinna zawierać tylko zmiany potrzebne do odtworzenia, naprawy i przetestowania blokera.

Pracuj w tej kolejności, bo późniejsze systemy zależą od wcześniejszych.

1. Udowodnij build release

Zbuduj dokładnie tę klasę binarki, która zawiodła. Na iOS użyj TestFlight albo równoważnej podpisanej ścieżki. Na Androidzie użyj artefaktu z internal testing. Sprawdź zmienne produkcyjne, endpointy, tożsamość bundle'a, uprawnienia i moduły natywne, zanim zaczniesz debugować kod ekranów.

Jeśli aplikacja działa w Expo Go, a wywala się po podpisaniu, obejrzyj granicę, która istnieje tylko w release. Typowe przyczyny to brakująca zmienna produkcyjna, niekompatybilna paczka natywna, rozjazd config pluginów, plik nieobecny w czystym buildzie albo praca przy starcie, która wywala się przed inicjalizacją raportowania błędów. Czytaj pierwszy sensowny błąd, nie ostatni komunikat opakowujący.

2. Ustabilizuj tożsamość i nawigację

Logowanie musi mieć jednego właściciela. Aplikacja powinna umieć odpowiedzieć, czy użytkownik jest zalogowany, czy onboarding jest skończony i który ekran ma się wyrenderować, gdy przywracanie sesji jeszcze trwa. Jeśli trzy ekrany podejmują te decyzje osobno, poprawka timeoutu w jednym z nich niczego nie ustabilizuje.

Przetestuj rejestrację, logowanie, odświeżenie tokenu, restart, wylogowanie, powrót z deep linka i usunięcie konta. Napraw przeterminowane sesje przed subskrypcjami. Zakup przypięty do jednej anonimowej tożsamości i późniejsze logowanie na inną potrafi wyglądać jak błąd SDK.

3. Napraw maszynę stanów płatnego dostępu

Traktuj paywall jak system. Produkty w sklepie, obsługa zakupu, tożsamość użytkownika, entitlements, restore purchases, anulowanie lub wygaśnięcie i strażnicy tras premium muszą się zgadzać. Wsadź płatny dostęp za jedno wspólne źródło entitlements zamiast sprawdzać lokalnego boola na każdym ekranie.

Przejdź zakupy nowe, nieudane i anulowane, a potem zrestartuj aplikację, zaloguj się ponownie, przeinstaluj i zrób restore. Wyniki wrzuć do analityki.

4. Domknij luki przed wysyłką

Naprawa głównego błędu nie oznacza gotowości do recenzji. Sprawdź świeżą instalację, stany offline, uprawnienia, prywatność, usuwanie konta, linki wsparcia, screenshoty, teksty o subskrypcji, notatki dla recenzenta i dane testowe. Potwierdź, że crash reporty i analityka startu przychodzą z builda release.

Skorzystaj z checklisty do wysyłki w App Store, żeby przejść cały sklep. Jeśli awaria dotyczy builda Expo albo crashuje tylko na TestFlight, porównaj ją z przewodnikiem po crashach na TestFlight.

5. Zdecyduj: naprawa czy przebudowa

Napraw istniejącą aplikację, kiedy problem ma jeden powtarzalny wyzwalacz, drzewo zależności jest na tyle świeże, że da się je wytłumaczyć, stan ma jasnych właścicieli, a punktowy test regresji udowodni naprawę.

Zatrzymaj się na audyt, jeśli wydanie sypie się na więcej niż jednej granicy, na przykład logowanie plus płatności, albo gdy kod wygenerowany przez AI rozkopiował logikę stanu i API po ekranach. Ratunek dla aplikacji w Silpho to ścieżka triage dla aplikacji zrobionych w Cursor, Lovable, Bolt, Replit, Rork i podobnych narzędziach, kiedy prawdziwe pytanie brzmi: co z tego ma przetrwać.

Przebuduj ścieżkę krytyczną, gdy każda łatka rodzi inną awarię, podpisane buildy pozostają nieprzewidywalne, logowanie i płatny dostęp nie mają centralnego źródła prawdy albo natywnych zależności nikt nie umie wyjaśnić. Zachowaj sprawdzone ekrany, teksty, grafiki, reguły produktowe i działającą logikę backendu.

Porównanie

Silpho Launch obejmuje 30-dniową gwarancję gotowości do wysyłki albo zwrot pieniędzy. Porównaj produktyzowane ścieżki z kosztem kolejnego cyklu niepewnych łatek na stronie cennika.

FAQ

Co liczy się jako awaria React Native przed premierą?

Bloker wydania: podpisana aplikacja się nie buduje, wywala przy starcie, gubi logowanie, psuje główny rezultat, źle obsługuje zakupy albo nie przechodzi wymaganej ścieżki wysyłki. Wada kosmetyczna też ma znaczenie, ale nie jest pierwszym incydentem, chyba że blokuje użycie albo wprowadza w błąd co do tego, za co użytkownik płaci.

Dlaczego aplikacja działa lokalnie, a pada na TestFlight?

Lokalny development i Expo Go nie odtwarzają wszystkich warunków wydania. Podpisany build może używać innych modułów natywnych, zmiennych produkcyjnych, uprawnień, optymalizacji, endpointów i mieć inne zachowanie przy starcie. Odtwórz problem w tej wadliwej binarce, zanim zaczniesz zmieniać kod.

Czy podnosić wersję React Native albo Expo w trakcie awaryjnej naprawy?

Tylko jeśli dowody wskazują, że obecna wersja jest przyczyną, a ścieżka aktualizacji jest zrozumiała. Szeroki upgrade frameworka zmienia zbyt wiele zmiennych naraz, zwłaszcza gdy bloker premiery to odizolowany problem konfiguracji, tożsamości albo entitlements.

Czy aktualizacja OTA naprawi bloker premiery?

Czasem tak, jeśli aplikacja ma już zgodny system aktualizacji, a zmiana mieści się w dozwolonej granicy JavaScriptu i zasobów. Moduły natywne, uprawnienia, podpisywanie, produkty w sklepie i część awarii przy starcie i tak wymagają nowej binarki oraz normalnych testów wydania.

Skąd mam wiedzieć, czy błąd jest w RevenueCat, czy w mojej aplikacji?

Oddziel zakończenie zakupu od kontroli dostępu. Jeśli sklep i RevenueCat zapisały transakcję, a aplikacja przyznaje zły dostęp, sprawdź tożsamość użytkownika, identyfikatory entitlements, odświeżanie customer info, cache i strażników tras, zanim obwinisz SDK.

Kiedy przestać prosić narzędzie AI o załatanie błędu?

Kiedy dwie łatki nie wyjaśniły przyczyny, kiedy narzędzie zmienia zależności bez planu wersji albo kiedy ta sama reguła stanu pojawia się na kilku ekranach. AI pomoże obejrzeć dowody i wdrożyć ograniczoną zmianę, ale nie przejmie odpowiedzialności za architekturę wydania.

Czy godzinna konsultacja wystarczy?

Może wystarczyć, jeśli awaria jest odizolowana, a zmianę wprowadzisz sam. Przeczytaj, kiedy konsultacja React Native ma sens, zanim wybierzesz Kickstart. Gdy niewiadomą jest sam kod, potrzebujesz audytu ratunkowego.

Czy naprawa blokera oznacza, że aplikacja jest gotowa do wysyłki?

Nie. Naprawiona binarka nadal potrzebuje testu świeżej instalacji, sprawdzenia cyklu życia i stanów błędu, przeglądu prywatności i usuwania konta, informacji o płatnościach, screenshotów, linków wsparcia, analityki, raportowania crashy i kompletnej ścieżki dla recenzenta.

Następne kroki

• Porównaj stałe ścieżki premiery i ceny

• Zacznij od Ratunku dla aplikacji, jeśli kod potrzebuje triage'u

• Sprawdź, czy wystarczy punktowa konsultacja React Native