Zgłoszenie aplikacji React Native do App Store: co musisz mieć przed wysyłką
Zanim wynajmiesz pomoc, sprawdź build, podpisywanie, prywatność, paywall, analitykę i materiały do recenzji, które powinna ogarnąć usługa zgłoszenia aplikacji React Native.
Twoja aplikacja React Native działa lokalnie, ale ostatnia prosta do TestFlight i App Review to miejsce, gdzie zaczynają sypać się podpisywanie, prywatność, paywalle i metadane.
Skrót
Usługa zgłoszenia aplikacji React Native do App Store przydaje się, gdy masz prawdziwy produkt, ale brakuje Ci dyscypliny wydawniczej. Słaba usługa tylko wrzuci build. Sensowna sprawdzi build produkcyjny, bundle ID, certyfikaty, szczegóły prywatności, usuwanie konta, zakupy w aplikacji, zachowanie entitlements w RevenueCat, analitykę, raportowanie crashy, zrzuty ekranu, notatki dla recenzenta i przekazanie. Jeśli kod jest niestabilny, pomoc przy zgłoszeniu go nie uratuje. Wybierz robotę własną, Kickstart, Launch albo Launch + Growth zależnie od tego, czy Twoim blokerem jest wiedza, pewność przy recenzji, zepsuta ścieżka produkcyjna, czy potrzeba pełnych materiałów premierowych i ASO.
Najważniejsze fakty
Zgłoszenie do App Store to nie jest jeden upload. To finalny test buildu, podpisywania, prywatności, metadanych i logiki produktu.
Aplikacje React Native oblewają recenzję z normalnych mobilnych powodów: zepsute logowanie, brak usuwania konta, niejasne subskrypcje, crashe, złe zrzuty ekranu i niepasujące odpowiedzi o prywatność.
Usługa powinna sprawdzić build wydaniowy, a nie tylko podgląd debugowy albo uruchomienie w symulatorze.
Jeśli sprzedajesz dostęp cyfrowy na iOS, paywall, restore purchases, stan entitlements i teksty informacyjne muszą być poprawne przed zgłoszeniem.
Prototypy zbudowane przez AI zwykle wymagają utwardzenia pod produkcję przed App Review, bo sukces w podglądzie nie dowodzi stabilności w TestFlight.
Jeśli aplikacja nie przechodzi TestFlight w powtarzalny sposób, zgłoś ją później. Najpierw napraw fundament.
Diagnoza: co się psuje przed zgłoszeniem
Błędem jest myślenie, że zgłoszenie do App Store zaczyna się w App Store Connect. Zaczyna się w repozytorium.
Kiedy aplikacja React Native jest gotowa do zgłoszenia, ścieżka produkcyjna powinna już działać na prawdziwym urządzeniu. Aplikacja instaluje się jako build wydaniowy, otwiera bez menu developerskiego, przywraca sesję użytkownika, pokazuje właściwy stan płatny albo darmowy, obsługuje brak sieci, usuwa konto (jeśli konta istnieją) i produkuje raporty crashy, gdy coś pójdzie źle. App Review to nie jest miejsce, gdzie odkrywasz te podstawy.
Większość zablokowanych founderów siedzi w jednym z czterech problemów.
Po pierwsze, build działa tylko w środowisku deweloperskim. Serwer Metro ukrywa brakujące zasoby, debugowy stan logowania, zignorowane zmienne środowiskowe i problemy z modułami natywnymi. Build wydaniowy zabiera te kule. Dlatego aplikacja potrafi wyglądać poprawnie w Expo Go albo w symulatorze i crashować, gdy tylko trafi na TestFlight.
Po drugie, podpisywanie i konfiguracja w sklepie są niespójne. Bundle ID, identyfikatory aplikacji, profile provisioningowe, wpisy w App Store Connect, entitlements, certyfikaty push i dane w EAS muszą wskazywać na tę samą aplikację. Usługa, która pomija to sprawdzenie, potrafi stracić kilka dni na gonieniu objawów.
Po trzecie, warstwa biznesowa jest niedokończona. App Review interesuje, czy użytkownik rozumie, co kupuje, czy potrafi przywrócić zakupy, usunąć konto, zobaczyć wymagane linki prawne i skorzystać z głównej funkcji bez ukrytej konfiguracji ręcznej. Ładny ekran paywalla to za mało, jeśli stan entitlements znika po restarcie.
Po czwarte, aplikacja została wygenerowana albo połatana do momentu, w którym nikt nie ufa już ścieżce kodu. Objawia się to zduplikowanymi helperami logowania, logiką płatności w losowych ekranach, przestarzałymi pakietami Expo, zmiennymi środowiskowymi w złym miejscu i ekranami działającymi tylko wtedy, gdy wejdziesz w nie w jednej konkretnej kolejności. W tym momencie blokerem nie jest zgłoszenie. Blokerem jest gotowość produkcyjna.
Ścieżka naprawy: co powinna robić prawdziwa usługa zgłoszenia
Dobra usługa zgłoszenia aplikacji React Native zaczyna od triage, nie od uploadu.
Pierwszy krok to zamrożenie zakresu. Żadnych nowych funkcji, żadnego redesignu, żadnej dodatkowej gałęzi onboardingu. Jedynym zadaniem jest udowodnienie, że wersja przeznaczona do zgłoszenia przetrwa użycie na prawdziwym urządzeniu, TestFlight i recenzję. Jeśli funkcja nie jest krytyczna dla zatwierdzenia albo pierwszego przychodu, wytnij ją z wydania.
Potem zbuduj artefakt produkcyjny. Przy aplikacjach Expo zwykle znaczy to produkcyjny build EAS i czystą ścieżkę submit. Przy bare React Native znaczy to zdrowy archive w Xcode, zachowanie schematu Release, sprawdzenie zależności natywnych i porządek w podpisywaniu. Build wydaniowy powinien być przetestowany na przynajmniej jednym fizycznym urządzeniu, zanim ktokolwiek dotknie metadanych w sklepie.
Następnie sprawdź wymagane systemy produktowe:
logowanie i przywracanie sesji
stan ukończenia onboardingu
usuwanie konta i linki prawne
wyświetlenie paywalla, zakup, restore i odświeżenie entitlements
zdarzenia analityczne dla rejestracji, onboardingu, wyświetlenia paywalla, startu zakupu, sukcesu zakupu, porażki zakupu i użycia głównej funkcji
raportowanie crashy w buildzie wydaniowym
odpowiedzi o prywatność zgodne z faktycznym zachowaniem SDK
zrzuty ekranu, podtytuł, opis, słowa kluczowe, kategorię wiekową i notatki dla recenzenta
Jeśli tych systemów brakuje, masz decyzję do podjęcia.
Napraw istniejący kod, gdy aplikacja się instaluje, nawigacja jest sensowna, zależności są wystarczająco aktualne, logowanie ma jedno źródło prawdy, a stan płatny da się scentralizować bez przepisywania całej aplikacji. To najszybsza droga, gdy aplikacja jest bałaganiarska, ale strukturalnie zrozumiała.
Zrób audyt, gdy nie potrafisz ocenić, czy aplikacja da się uratować. To częste przy budowach z Cursorem, Lovable, Bolt, Replit, Rork i podobnymi. Właściwe pytanie nie brzmi "czy ktoś to zgłosi?". Właściwe pytanie brzmi "co musi być prawdą, zanim to zasłuży na zgłoszenie?".
Przebuduj krytyczną ścieżkę, gdy aplikacja nie ma stabilnego modelu danych, fundament SDK jest uszkodzony, ekrany duplikują logikę biznesową albo podgląd jest w praktyce webowym demo udającym produkt natywny. Przebudowa to nie porażka. Często jest tańsza niż przepychanie kruchego prototypu przez proces recenzji, którego nie przetrwa.
Silpho jest zbudowane wokół tego rozróżnienia. Przy budowach prowadzonych przez foundera Kickstart daje boilerplate plus review 1 na 1 i wsparcie. Przy pracy zrobionej za Ciebie cennik Silpho pokrywa ścieżki o stałym zakresie na iOS albo iOS plus Android. Przy prototypach AI, które potrzebują produktu, przychodu, analityki i egzekucji w App Store, sprint premiery produktu AI jest czystszą drogą niż płacenie komuś za wrzucenie niestabilnego kodu.
Porównanie
| Ścieżka | Koszt | Dla kogo | Ryzyko |
|---|---|---|---|
| Samodzielnie z Ship React Native Full | 799 zł | Techniczni founderzy, którzy ogarną podpisywanie, buildy, metadane i poprawki po recenzji | Każdy błąd w App Store, TestFlight, prywatności i paywallu jest Twój |
| Kickstart | 1 990 zł netto | Founderzy, którzy umieją budować, ale chcą boilerplate'u, sesji 1 na 1, code review i 30 dni wsparcia | Zgłoszenie i tak wykonujesz sam |
| Launch | 15 900 zł netto z iOS i Androidem | Founderzy chcący czterotygodniowej ścieżki zrobionej za nich, z dyscypliną wydawniczą | Zakres musi zostać wąski na tyle, żeby zmieścił się w stałej ścieżce |
| Launch + Growth | 23 900 zł netto z iOS i Androidem | Produkty gotowe na przychód, które potrzebują też pełnych materiałów premierowych i ASO | Większy budżet niż zwykły upload, ale mocniejszy pod odkrywalność i konwersję w sklepie |
| Sama pomoc przy zgłoszeniu | Na wycenę | Aplikacje już gotowe na produkcję, którym brakuje tylko obsługi App Store Connect | Może zamaskować prawdziwy problem, jeśli aplikacja nie jest gotowa |
FAQ
Co powinna obejmować usługa zgłoszenia aplikacji React Native do App Store?
Weryfikację buildu wydaniowego, sprawdzenie podpisywania, konfigurację App Store Connect, przegląd prywatności i kwestii prawnych, metadane, zrzuty ekranu, przejście przez TestFlight i samo zgłoszenie. Przy aplikacjach płatnych albo subskrypcyjnych także weryfikację informacji o paywallu, zakupów, restore purchases i zachowania entitlements.
Czy ktoś może zgłosić moją aplikację React Native bez zmian w kodzie?
Czasem, ale tylko jeśli aplikacja jest już gotowa na produkcję. Jeśli build wydaniowy crashuje, logowanie pada po restarcie, brakuje usuwania konta albo paywall omija entitlements, kod musi się zmienić przed zgłoszeniem.
Czy potrzebuję TestFlight przed zgłoszeniem do App Store?
Tak, jeśli zależy Ci na unikaniu odrzuceń i crashy w dniu premiery. TestFlight to miejsce, gdzie potwierdzasz, że build wydaniowy instaluje się, otwiera, loguje, kupuje, przywraca zakupy i raportuje crashe poza lokalnym środowiskiem deweloperskim.
Czy React Native utrudnia zatwierdzenie w App Store?
Nie. Apple recenzuje doświadczenie aplikacji, a nie to, czy UI napisano w React Native. Typowe porażki są normalnymi porażkami mobilnymi: zepsuta funkcjonalność, niejasne płatności, brakujące dane o prywatności, złe metadane albo crashe.
Co, jeśli aplikacja powstała w Cursorze, Lovable, Bolt albo Replit?
Nie zgłaszaj podglądu tylko dlatego, że wygląda na skończony. Aplikacje budowane przez AI zwykle potrzebują audytu produkcyjnego zależności, modułów natywnych, stanu logowania, logiki płatności, wymogów prywatności, analityki, raportowania crashy i materiałów do sklepu. Jeśli krytyczna ścieżka jest zdrowa, napraw ją. Jeśli fundament jest poplątany, przebuduj ścieżkę do premiery.
Czy mogę użyć Stripe zamiast zakupów w aplikacji Apple?
To zależy od tego, co sprzedajesz i gdzie zakup jest konsumowany. Dostęp cyfrowy konsumowany w aplikacji iOS zwykle wymaga systemu zakupów w aplikacji Apple, często zarządzanego przez RevenueCat. Towary fizyczne, usługi poza aplikacją i część przypadków biznesowych mają inne zasady, więc sprawdź to przed zbudowaniem przepływu płatności.
Wynająć pomoc przy zgłoszeniu czy najpierw przebudować aplikację?
Najpierw przebuduj, jeśli aplikacja nie potrafi wyprodukować stabilnego buildu wydaniowego, nie ma wiarygodnego stanu logowania albo rozsypuje logikę płatności po wielu ekranach. Wynajmij pomoc przy zgłoszeniu, gdy produkt działa, a jedynym problemem jest egzekucja wydania.
Która oferta Silpho pasuje do tego problemu?
Ship React Native, jeśli chcesz boilerplate'u za 799 zł do roboty własnej. Kickstart, jeśli chcesz review i prowadzenia. Launch albo Launch + Growth, jeśli chcesz, żeby Silpho wzięło na siebie stałą ścieżkę do aplikacji gotowej do wydania.