Appka od AI odrzucona przez App Store: diagnoza, naprawa, ponowna wysyłka

Apple odrzuciło build, który w podglądzie wyglądał na skończony, a wiadomość z recenzji nie mówi, który wygenerowany skrót na tym zawinił.

W skrócie

Appka zbudowana przez AI potrzebuje precyzyjnej naprawy, a nie kolejnego szerokiego promptu. Zapisz pełną wiadomość od Apple, znajdź cytowaną wytyczną i odrzucony element, a potem sklasyfikuj problem: brak dowodu dla recenzenta, błędne metadane albo zepsute zachowanie produktu. Problem z metadanymi często nie wymaga nowego builda. Crashe, usuwanie konta, auth, płatności i entitlementy prawie zawsze wymagają zmian w kodzie i testów na buildzie releasowym. Napraw istniejącą appkę, kiedy jedna przyczyna jest powtarzalna, a architektura releasu jest jasna. Zrób audyt, kiedy kilka systemów mówi co innego. Przepisz krytyczną ścieżkę, kiedy auth, płatny dostęp, własność danych albo konfiguracja natywna nie mają żadnego właściciela.

Najważniejsze fakty

• Apple recenzuje wysłany produkt i dowody, a nie to, czy kod napisał Cursor, Lovable, Bolt, Replit, Rork czy ktokolwiek inny.

• Wiadomość o odrzuceniu, cytowana wytyczna, zrzuty ekranu, odrzucony element, numer builda i kroki recenzenta to Twoja dokumentacja incydentu.

• Poprawka metadanych czasem obchodzi się tą samą binarką, defekt zachowania wymaga przetestowanego builda zastępczego.

• Wygenerowany paywall nie jest systemem płatności, dopóki produkty, zakupy, entitlementy, restore i reguły dostępu nie mówią jednym głosem.

• Appki, które zakładają konta, muszą mieć widoczną ścieżkę usunięcia konta, która naprawdę je usuwa, a nie tylko wylogowuje albo dezaktywuje.

• Napraw jedną odizolowaną awarię, zaudytuj awarie, które na siebie wpływają, przepisz, kiedy każda łatka odsłania kolejną niestabilną granicę.

• Przejście recenzji nie dowodzi retencji ani przychodu, ale oblanie jej dowodzi, że ścieżka do premiery jest niedokończona.

Diagnoza: zamień odrzucenie w testowalną awarię

Nie wklejaj odrzucenia do narzędzia AI i nie przyjmuj pierwszej łatki. Wiadomość od Apple może prosić o informacje, kwestionować dane w listingu albo wskazywać zepsute zachowanie. To trzy różne ścieżki.

Otwórz sekcję App Review w App Store Connect i zachowaj:

1. pełną wiadomość recenzenta z cytowaną wytyczną;

2. każdy zrzut ekranu i załącznik od Apple;

3. odrzucony element, czyli wersję appki, subskrypcję albo metadane listingu;

4. wysłaną wersję i numer builda;

5. dane logowania recenzenta, konfigurację, urządzenie i kroki odtworzenia;

6. commit i środowisko produkcyjne użyte do tego builda.

Pomoc App Store Connect mówi wprost, że możesz odpowiedzieć App Review i dołączyć zrzuty ekranu albo dokumenty. Użyj tego kanału, kiedy recenzent przegapił ścieżkę, potrzebuje działającego konta albo źle zrozumiał produkt. Nie wysyłaj builda na wyczucie, kiedy prawdziwym problemem jest brak dowodu.

Sklasyfikuj odrzucenie, zanim cokolwiek zmienisz.

Brak dowodu dla recenzenta: funkcja istnieje, ale wygasłe konto testowe, onboarding, konfiguracja regionalna, brak danych albo słabe notatki blokują recenzentowi dojście do niej.

Rozjazd metadanych albo polityki: zrzuty ekranu, opis subskrypcji, odpowiedzi o prywatność, linki wsparcia, uprawnienia albo opisy produktu nie zgadzają się z działającą binarką. Część poprawek metadanych obchodzi się tym samym buildem.

Awaria zachowania produktu: build releasowy się wysypuje, gubi sesje, pokazuje niedokończone treści albo nie dowozi reklamowanego rezultatu. To wymaga powtarzalnej poprawki w kodzie i nowych testów releasowych.

Awaria przychodu: produkt w sklepie, tożsamość zakupu, entitlement, dostęp premium albo restore nie działają. To problem systemu płatności, nie przycisku.

Awaria konta i prywatności: rejestracja nie ma usuwania konta, zbierane dane różnią się od odpowiedzi o prywatność albo uprawnienie nie ma jasnego celu. Wytyczne Apple o usuwaniu konta wymagają inicjowania procesu w appce.

Generowanie kodu faworyzuje widoczny happy path. App Review testuje system pomiędzy wygenerowanymi ekranami: konfigurację releasu, trwałą tożsamość, efekty po stronie backendu, stan zakupu, odzyskiwanie, usuwanie i rzetelność obietnic.

Naprawa: napraw odrzuconą warstwę, potem udowodnij całą ścieżkę recenzenta

Zacznij od najmniejszej zmiany, która w pełni odpowiada na wiadomość z recenzji. Zamroź niepowiązane funkcje, żeby ponowna wysyłka miała jeden wytłumaczalny cel.

Przy problemie z dowodem albo dostępem zweryfikuj konto recenzenta na czystym urządzeniu. Usuń założenia z onboardingu, wgraj potrzebne dane i napisz numerowane notatki ze ścieżką ekranów i oczekiwanym rezultatem. Dołącz dowody, jeśli wyjaśniają ukrytą ścieżkę.

Przy problemie z metadanymi dopasuj wpis w sklepie do builda. Sprawdź zrzuty ekranu, obietnice, korzyści z subskrypcji, politykę prywatności, adres wsparcia, kategorię wiekową, deklarację zbieranych danych i uprawnienia. W odpowiedzi wypisz dokładnie zmienione pola.

Przy problemie z zachowaniem releasu odtwórz go na tej samej klasie binarki, która została odrzucona. Expo Go i symulatory są słabym zamiennikiem TestFlight. Przetestuj czystą instalację, zimny start, wolną sieć, odmowę uprawnień, zmianę cyklu życia, przywracanie sesji, wylogowanie i główny rezultat AI.

Przy problemie z płatnościami prześledź jedną maszynę stanów:

produkt w sklepie -> zakup -> paragon lub rekord klienta -> entitlement -> dostęp w appce -> restart -> restore

Używaj jednego stabilnego ID użytkownika po zalogowaniu i jednego wspólnego źródła entitlementów. Przetestuj nowy zakup, anulowanie, błąd, restart, reinstalację i restore w sandboxie sklepu. Lokalna flaga isPremium potrafi sprawić, że demo wygląda na opłacone, podczas gdy App Review widzi zepsuty zakup.

Przy problemie z usuwaniem konta umieść tę opcję widocznie w ustawieniach konta. Upewnij się, że akcja faktycznie usuwa konto i powiązane dane, wylogowuje użytkownika i osobno wyjaśnia kwestię rozliczenia subskrypcji. Link do polityki prywatności, mail do supportu ani wylogowanie to nie jest to samo.

Zanim wyślesz ponownie, przejdź ścieżkę recenzenta od świeżej instalacji i przygotuj krótką odpowiedź:

• zacytuj wytyczną i przyznaj, co faktycznie nie działało;

• nazwij dokładną zmianę;

• podaj ścieżkę ekranów i konto testowe;

• wskaż nowy build, jeśli zmienił się kod;

• dołącz dowody, jeśli naprawa nie jest oczywista;

• zadaj jedno konkretne pytanie, jeśli instrukcja Apple jest niejasna.

Potem zrób szerszy przegląd przed premierą. Pierwsze odrzucenie potrafi zasłaniać drugi bloker. Sprawdź auth, główny workflow AI, płatności, usuwanie konta, prywatność, analitykę, crash reporting, linki wsparcia, zrzuty ekranu i dostęp recenzenta. Przewodnik po ryzykach przed wysyłką pokrywa to, o czym jedna wiadomość o odrzuceniu może nie wspomnieć.

Zdecyduj: naprawa, audyt czy przepisanie

Napraw obecną appkę, kiedy odrzucenie mapuje się na jedną jasną przyczynę, build releasowy jest poza tym stabilny, auth i stan entitlementów mają właścicieli, a test regresyjny potwierdza poprawkę.

Zatrzymaj się na audyt, kiedy dwie granice albo więcej wykładają się razem. Przykłady: logowanie zmienia tożsamość płatniczą, usunięcie konta zostawia dane na backendzie, build releasowy używa innych usług niż podgląd. Ratunek dla aplikacji to ścieżka triage dla generowanych appek w React Native i Expo, kiedy bloker przestał być jednym ticketem, a stał się niepewnością co do tego, co w ogóle ma przetrwać.

Przepisz krytyczną ścieżkę, kiedy nikt nie potrafi wytłumaczyć drzewa zależności, podpisane buildy dalej są nieprzewidywalne, reguły biznesowe są skopiowane po ekranach albo każda łatka rodzi kolejną awarię. Zachowaj przydatne ekrany, markę, copy, assety, przetestowaną logikę backendu i zwalidowane decyzje produktowe. Wymień niestabilną infrastrukturę premiery bez sentymentu do wygenerowanego kodu.

Porównanie

Silpho Launch ma 30-dniową gwarancję gotowości do wysyłki albo pełny zwrot. Porównaj dostępne ścieżki na cenniku Silpho, zanim zapłacisz za kolejną serię niepowiązanych łatek.

FAQ

Czy Apple odrzuci appkę dlatego, że kod napisało AI?

Nie. Apple recenzuje wartość appki, jej zachowanie, płatności, prywatność, metadane i zgodność z zasadami. Generowanie kodu przez AI ma znaczenie tylko wtedy, gdy zostawiło w wysłanej paczce widoczne wady produktowe albo produkcyjne.

Czy po każdym odrzuceniu potrzebuję nowego builda?

Nie. Braki w informacjach i część problemów z metadanymi da się rozwiązać w App Store Connect bez wymiany binarki. Crash, zepsuty przepływ, defekt płatności albo brak usuwania konta wymagają zmian w kodzie i nowego, przetestowanego builda.

Czy odpisać App Review przed zmianą kodu?

Odpisz najpierw, kiedy wiadomość jest niejednoznaczna, recenzent potrzebuje dostępu albo appka już zachowuje się poprawnie i potrafisz to udowodnić. Kiedy defekt jest jasny i powtarzalny, napraw go, przetestuj i wyjaśnij zmianę w notatkach do ponownej wysyłki.

Dlaczego appka przeszła TestFlight, a poległa na App Review?

Dystrybucja przez TestFlight dowodzi, że Apple przyjęło build do testów, a nie że każdy przepływ i każda reguła sklepu są w porządku. App Review sprawdza dodatkowo metadane, płatności, prywatność, dostęp recenzenta i zachowanie, które Apple potrafi odtworzyć.

Czy odrzucenie zakupu w appce naprawię zmianą treści na paywallu?

Tylko jeśli odrzucenie dotyczy wyłącznie nieprecyzyjnej albo brakującej informacji. Jeśli zepsuty jest zakup, entitlement, restore, tożsamość użytkownika albo płatny dostęp, zmiana treści zostawia system przychodu w tym samym stanie.

Czy brak usuwania konta to poprawka tylko po stronie frontu?

Zwykle nie. Interfejs musi udostępnić akcję, ale backend też musi usunąć konto i powiązane dane albo obsłużyć zgłoszenie usunięcia. Potem appka potrzebuje przewidywalnego stanu wylogowanego i jasnej informacji o subskrypcji.

Kiedy Kickstart wystarczy przy odrzuceniu z App Store?

Kickstart pasuje founderowi, który sam wprowadzi zmiany i potrzebuje produkcyjnego boilerplate'u, prowadzenia jeden na jeden, code review i 30 dni wsparcia. Sięgnij po triage ratunkowy, kiedy w kodzie jest kilka powiązanych awarii albo decyzja naprawa kontra przepisanie jest niejasna.

Kiedy przepisać zamiast wysyłać kolejną łatkę?

Przepisz krytyczną ścieżkę, kiedy auth, płatności, dostęp do danych i nawigacja nie mają stabilnego właściciela, buildy releasowe zostają nieprzewidywalne albo każda naprawa rodzi kolejną awarię. Nie przepisuj tylko dlatego, że jedno pole metadanych albo pojedynczy bug oblały recenzję.

Następne kroki

• Porównaj sztywne zakresy i ceny Silpho

• Zacznij od Ratunku dla aplikacji, jeśli kod wymaga triage

• Sprawdź ryzyka przed wysyłką appki zbudowanej przez AI