Aplikacja odrzucona w App Store: jak przygotować się do review

Aplikacja odrzucona w App Store to zwykle nie wynik złej woli recenzenta, tylko braku czegoś, czego Apple wymaga, a czego zespół nie sprawdził przed wysyłką: konta testowego, działającego logowania, opisu subskrypcji albo stabilnego pierwszego uruchomienia. Zajmujemy się publikacją i utrzymaniem aplikacji mobilnych, między innymi dla bambiboo.eu i feelya.ai. Z tej pracy wynika lista kontrolna, którą sprawdzamy przed każdą wysyłką buildu do App Store i Google Play.

Dlaczego aplikacja zostaje odrzucona w App Store

Recenzent Apple sprawdza, czy aplikacja działa, czy da się ją w pełni przetestować i czy spełnia zasady z wytycznych App Store Review Guidelines. Wytyczne wprost wymagają, żeby przy aplikacji z logowaniem podać dane konta demonstracyjnego i mieć włączony backend, a aplikacje, które się zawieszają albo mają oczywiste problemy techniczne, są odrzucane.

Najczęściej chodzi o kilka obszarów:

• Logowanie: brak konta testowego, konto bez danych, na którym recenzent nie zobaczy funkcji, albo logowanie przez zewnętrzny serwis bez równoważnej opcji, której wymagają wytyczne.
• Usuwanie konta: jeśli aplikacja pozwala założyć konto, musi też pozwalać je usunąć z poziomu aplikacji.
• Subskrypcje: niejasne, co użytkownik dostaje za cenę, albo brak informacji o aktywnej subskrypcji w aplikacji.
• Biały ekran po instalacji: aplikacja startuje, ale nie ładuje treści, bo czeka na serwer, konfigurację albo uprawnienie.

Każdy z tych punktów da się sprawdzić przed wysyłką. Gdy tego zabraknie, aplikacja odrzucona w App Store wraca do zespołu, poprawka przechodzi kolejne review, a termin startu przesuwa się o czas, którego nikt nie zaplanował.

Zgłoszenia użytkowników, które mówią to samo co recenzent

Problemy, które zatrzymują review, wracają po publikacji jako zgłoszenia i niskie oceny. Różnica polega na tym, że recenzent opisze problem, a użytkownik po prostu odinstaluje aplikację.

• biały ekran po pierwszym uruchomieniu, na przykład przy słabym zasięgu albo po aktualizacji, gdy w telefonie zostały stare dane,
• brak możliwości zalogowania po zmianie hasła na stronie,
• link do resetu hasła, który otwiera przeglądarkę zamiast aplikacji, ląduje w spamie albo wygasa, zanim użytkownik go kliknie,
• subskrypcja kupiona na stronie, której nie widać w aplikacji.

Subskrypcja widoczna w aplikacji to temat osobny. Jeśli klient płaci na stronie sklepu, na przykład przez BLIK, aplikacja musi pokazywać ten sam status z tego samego źródła danych. Pisałem o tym przy wdrażaniu subskrypcji z BLIK-iem powtarzalnym. Przy treściach cyfrowych kupowanych w aplikacji dochodzą jeszcze zasady zakupów w aplikacji Apple, więc model płatności warto ustalić przed budową, a nie tydzień przed review.

Google Play: polityki i klucze podpisu

Google Play ma własne wymagania. Polityki dla deweloperów dotyczą między innymi danych użytkowników, uprawnień i treści, a deklaracja bezpieczeństwa danych w konsoli musi zgadzać się z tym, co aplikacja naprawdę zbiera. Rozbieżność może zatrzymać aktualizację.

Przed wydaniem produkcyjnym warto wypuścić build na ścieżkę testów wewnętrznych w Google Play i do TestFlight po stronie Apple. Kilka osób spoza zespołu na prawdziwych telefonach wyłapie biały ekran czy nieudany reset hasła szybciej niż recenzent, i bez wpisu w historii odrzuceń.

Drugi temat to klucze podpisu. Przy Play App Signing są dwa klucze: klucz podpisywania aplikacji, którym zarządza Google, i klucz przesyłania, którym zespół podpisuje build przed wysłaniem, co opisuje dokumentacja podpisywania aplikacji na Androida. Zgubiony albo przejęty klucz przesyłania da się zresetować w konsoli, ale tylko wtedy, gdy ktoś w firmie ma do niej dostęp. Dlatego klucze i konta deweloperskie Apple i Google powinny należeć do firmy, a nie do wykonawcy czy jednego pracownika.

Lista kontrolna przed wysłaniem buildu do review

Przed każdym wydaniem, nie tylko pierwszym, przechodzę te punkty:

1. Konto demonstracyjne z danymi, które pokazują wszystkie funkcje, i backend włączony przez cały czas review.
2. Logowanie, rejestracja, reset hasła i usuwanie konta przetestowane na czystym telefonie.
3. Subskrypcje: opis, co użytkownik dostaje, cena, status widoczny w aplikacji, przywracanie zakupów.
4. Pierwsze uruchomienie na świeżej instalacji, przy słabym zasięgu i bez zgody na powiadomienia.
5. Opis w sklepie, zrzuty ekranu i polityka prywatności zgodne z tym, co aplikacja robi.
6. Deklaracja bezpieczeństwa danych w Google Play zgodna z faktycznym zbieraniem danych.
7. Klucze podpisu i dostępy do kont deweloperskich zapisane po stronie właściciela aplikacji.
8. Notatka dla recenzenta: jak dojść do kluczowych funkcji i czego wymaga konto testowe.

Ta lista powinna być częścią procesu wydania, a nie dokumentem, który ktoś otwiera po odrzuceniu. Szerzej o drodze od pomysłu do publikacji piszę w tekście o aplikacjach mobilnych dla biznesu.

Co zrobić, gdy aplikacja i tak zostanie odrzucona

Odrzucenie przychodzi z numerem wytycznej i opisem, więc najpierw sprawdź, czego dokładnie dotyczy. Jeśli recenzent się pomylił, odpowiedz rzeczowo w App Store Connect, najlepiej z nagraniem ekranu albo instrukcją krok po kroku. Jeśli miał rację, popraw błąd i wyślij nowy build z notatką, co się zmieniło. Spór rzadko przyspiesza publikację, a rzeczowa odpowiedź zwykle tak.

Czas na review i ewentualne poprawki warto wliczyć w harmonogram od początku, szczególnie gdy termin startu jest związany z kampanią albo sezonem. Piszę o tym przy temacie, jak zaplanować MVP aplikacji.

Jeśli Twoja aplikacja odrzucona w App Store czeka na poprawki albo dopiero szykujesz pierwszą publikację, przejdź listę kontrolną przed wysłaniem buildu i ustal, kto w firmie ma klucze i dostęp do kont deweloperskich. Gdy chcesz zrobić to z zespołem, który publikuje aplikacje na co dzień, poznaj zasady współpracy ze mną.