Odrzucenie App Store 2.1 App Completeness: plan testów wersji release przed ponownym zgłoszeniem (2026)

Odrzucenie w App Store na podstawie wytycznej 2.1 App Completeness oznacza, że recenzent nie mógł korzystać z aplikacji tak, jak zrobiłby to klient. Aplikacja mogła się zawiesić, pokazać treści zastępcze, zablokować go na ekranie logowania lub ukryć zakup w aplikacji. Rozwiązaniem rzadko jest jedna linijka kodu. Przed ponownym zgłoszeniem przeprowadź krótki plan testów na wersji release, korzystając ze świeżej instalacji i tych samych danych logowania, które przekazujesz App Review. Ten artykuł omawia ten plan krok po kroku i pokazuje, jak inni deweloperzy poradzili sobie z tym samym odrzuceniem.

Co sprawdza wytyczna App Store 2.1 App Completeness?

Wytyczna 2.1 sprawdza, czy zgłoszony build jest gotową, działającą aplikacją. Potrzebne są kompletne metadane, działające linki, logowanie demo, aktywny backend oraz zakupy w aplikacji, które recenzent może znaleźć i wykorzystać.

Wytyczne App Review Apple dzielą punkt 2.1 na dwie części. 2.1(a) mówi, że zgłoszenia „powinny być wersjami ostatecznymi, zawierającymi wszystkie niezbędne metadane i w pełni działające adresy URL”, a tekst zastępczy i puste strony internetowe należy usunąć. Nakazuje też przetestować aplikację na urządzeniu pod kątem błędów i stabilności oraz „dołączyć dane konta demo (i włączyć usługę backendową!), jeśli aplikacja zawiera logowanie”. Apple „odrzuci niekompletne paczki aplikacji i pliki binarne, które crashują lub wykazują oczywiste problemy techniczne”. 2.1(b) mówi, że zakupy w aplikacji muszą być „kompletne, aktualne, widoczne dla recenzenta i działające”. Jeśli skonfigurowanego zakupu nie da się znaleźć w aplikacji, wyjaśnij dlaczego w notatkach dla recenzenta.

To częste odrzucenie. Strona Apple Preparing for App Review podaje: „Średnio ponad 40% nierozwiązanych problemów dotyczy wytycznej 2.1: App Completeness, która obejmuje crashe, treści zastępcze, niekompletne informacje i nie tylko”.

Dlaczego testowanie buildu debug nie wyłapuje problemów z 2.1?

Build debug nie działa tak, jak kopia recenzenta. Recenzent instaluje podpisany dystrybucyjnie build release na czystym urządzeniu, bez zapisanej sesji i bez skrótów debugowych.

Twój symulator jest już zalogowany. Lokalne API może wskazywać na serwer staging, który nigdy nie pada. Flagi debugowania omijają paywall, a feature flagi są domyślnie włączone. Recenzent nie ma nic z tego. Strona Apple o weryfikacji prosi też o „dokładne testy na urządzeniach z najnowszym oprogramowaniem”, więc recenzent może korzystać z nowszej wersji iOS niż Twój telefon testowy.

TestFlight to najbliższe odwzorowanie środowiska recenzenta. Według przeglądu TestFlight możesz dodać do 100 testerów wewnętrznych z zespołu App Store Connect i do 10 000 testerów zewnętrznych. Build można testować do 90 dni. Wgraj dokładnie ten build, który planujesz zgłosić, zainstaluj go z TestFlight na urządzeniu, na którym aplikacja nigdy nie była uruchamiana, i testuj tę kopię.

Co powinien obejmować plan testów wersji release przed ponownym zgłoszeniem?

Plan testów wersji release sprawdza każde miejsce, w którym nowy recenzent może utknąć: uruchomienie, uprawnienia, logowanie, backend, treści, linki, zakupy, awarie sieci i iPada. Wykonaj kroki po kolei na buildzie z TestFlight i zapisuj każdy wynik, aby móc go przytoczyć w notatkach dla recenzenta.

1. Czysta instalacja na najnowszym iOS. Usuń wcześniejszą kopię, zainstaluj z TestFlight i uruchom bez zapisanego stanu. Wykonaj trzy zimne starty i potwierdź, że onboarding się nie crashuje.
2. Odmów każdej prośbie o uprawnienia przynajmniej raz. Odrzuć powiadomienia, lokalizację, aparat i śledzenie. Aplikacja nadal powinna dojść do używalnego ekranu. Sprawdź też, czy Info.plist zawiera opis użycia dla każdego chronionego zasobu, z którego korzysta aplikacja lub jej SDK.
3. Zaloguj się dokładnie tymi danymi demo. Skopiuj je z App Store Connect, a nie z menedżera haseł. Konto powinno mieć realistyczne dane, nie wymagać weryfikacji e-mail i nie używać uwierzytelniania dwuskładnikowego powiązanego z Twoim telefonem.
4. Potwierdź, że backend jest produkcyjny i działa. Build musi wskazywać na produkcyjne endpointy. Limity zapytań, listy dozwolonych adresów IP i geoblokady nie mogą zablokować recenzenta. Wytyczna 2.1(a) nakazuje włączyć usługę backendową.
5. Przejdź przez każdą zakładkę i ekran. Szukaj lorem ipsum, ekranów „Wkrótce”, pustych stanów bez wyjaśnienia, testowych obrazków i przycisków, które nic nie robią.
6. Kliknij każdy link. Dotyczy to polityki prywatności, wsparcia, regulaminu i wszelkich widoków webowych. Apple podaje: „Link do wsparcia użytkowników z aktualnymi danymi kontaktowymi oraz link do polityki prywatności są wymagane we wszystkich aplikacjach”.
7. Otwórz każdy zakup w aplikacji. Zaloguj się jako nowe konto. Sprawdź, czy każdy produkt zgłoszony z daną wersją pojawia się z ceną, da się go kupić w sandboksie i czy działa Restore Purchases.
8. Przetestuj na wolnej lub zerwanej sieci. Włącz tryb samolotowy w trakcie jakiegoś procesu. Czytelny komunikat o błędzie jest w porządku. Niekończący się spinner albo crash — nie.
9. Sprawdź iPada, jeśli go obsługujesz. Jeśli aplikacja działa na iPadzie, uruchom ją tam i upewnij się, że układ nie zablokuje użytkownika.

Konto demo z kroku 3 powoduje więcej powtórnych odrzuceń niż jakikolwiek inny krok. Nasz poradnik o konfiguracji konta demo do weryfikacji w App Store pokazuje, jak przygotować konto, które przetrwa.

Jak dopasować komunikat odrzucenia 2.1 do poprawki?

Aby dopasować odrzucenie 2.1 do poprawki, przeczytaj zdanie po numerze wytycznej. Wskazuje ono objaw, a każdy objaw prowadzi do jednego kroku planu testów.

Załóżmy, że aplikacja do śledzenia nawyków zostaje odrzucona z komunikatem „We were unable to review the app because it crashed on launch” (nie mogliśmy zweryfikować aplikacji, ponieważ crashowała przy uruchomieniu). Druga uwaga mówi, że recenzent nie mógł znaleźć zakupów w aplikacji. Poniższa tabela łączy typowe objawy z przyczyną, testem i poprawką.

Szerszą metodę odczytywania każdego komunikatu odrzucenia znajdziesz w artykule Odrzucenie w App Store: jak to naprawić, wytyczna po wytycznej.

Jak wyglądały odrzucenia 2.1 u innych deweloperów?

Publiczne przypadki 2.1 mają wspólny schemat. Aplikacja działa w środowisku dewelopera, a zawodzi u recenzenta z powodu czegoś, co ujawnia dopiero świeża instalacja lub logowanie przez obcą osobę.

• Crash z powodu brakującego opisu użycia. Na forach Solar2D deweloper otrzymał komunikat „We were unable to review the app because it crashed on launch” na iPhonie 13 mini z iOS 18.3.2, choć aplikacja działała w TestFlight. Inny użytkownik znalazł w załączonym logu crasha: „This app has crashed because it attempted to access privacy-sensitive data without a usage description” (aplikacja się zawiesiła, ponieważ próbowała uzyskać dostęp do danych wrażliwych dla prywatności bez opisu użycia). Deweloper napisał: „Przeszło po dodaniu: NSUserTrackingUsageDescription”.
• Logowanie społecznościowe, z którego recenzent nie mógł skorzystać. Deweloper na Apple Developer Forums zgłosił wielokrotne odrzucenia 2.1, ponieważ recenzenci „nie mogli użyć logowania społecznościowego”. Przekazał konta demo Apple i Google, ale logowanie przez Apple ID wymagało kodu weryfikacyjnego wysyłanego na telefon dewelopera. Pracownik Apple odpowiedział, że App Review skontaktuje się z nim bezpośrednio. Publicznego rozwiązania nie opublikowano.
• Zakupów w aplikacji „nie znaleziono w zgłoszonym pliku binarnym”. W wątku społeczności RevenueCat deweloper został odrzucony, ponieważ w pliku binarnym nie znaleziono planu miesięcznego, choć zakupy w sandboksie działały. Jedna z osób pomagających napisała, że podobne odrzucenie rozwiązano, odpowiadając szczegółową instrukcją i zrzutami ekranu każdej ścieżki do paywalla. Zespół RevenueCat doradził pokazanie każdego zgłoszonego produktu na domyślnym paywallu i trzymanie plików testowych StoreKit poza schematem Archive.

We wszystkich trzech przypadkach własne testy dewelopera przechodziły. Błąd pojawiał się dopiero z perspektywy recenzenta: bez telefonu do 2FA, bez wcześniejszej sesji i bez wiedzy, gdzie jest paywall. Właśnie tę perspektywę odtwarza powyższy plan testów.

Co powinny zawierać notatki dla App Review po odrzuceniu 2.1?

Notatki dla recenzenta po odrzuceniu 2.1 powinny zawierać działające dane demo, listę zmian od odrzuconego buildu oraz dokładne wskazanie, gdzie znaleźć zakupy w aplikacji i mniej oczywiste funkcje.

Strona Apple o weryfikacji zaleca umieszczenie danych konta i specjalnej konfiguracji w sekcji App Review Information. Jeśli funkcja wymaga sprzętu lub środowiska trudnego do przygotowania, „bądź gotów dostarczyć wideo demonstracyjne lub sprzęt”. Wytyczna 2.3.1(a) dodaje, że nowe funkcje muszą być opisane „konkretnie” w Notes for Review, a „ogólnikowe opisy zostaną odrzucone”. Dobrze sprawdza się krótka, uporządkowana notatka:

Demo account: review@example.com / (password)
Account is pre-verified, has no 2FA and has 30 days of sample data.

Fixes since last submission (2.1):
- Launch crash on fresh install fixed (tested build 42 on latest iOS, clean device).
- In-app purchases: Settings > Upgrade shows Monthly and Yearly.
- Backend is production and will stay live during review.

Non-obvious features:
- Widgets: long-press Home Screen > add "Streaks" widget.

Jeśli obowiązki prawne lub wymogi bezpieczeństwa wykluczają konto demo, wytyczna 2.1(a) dopuszcza wbudowany tryb demo, ale wyłącznie za uprzednią zgodą Apple, a tryb ten musi pokazywać pełne funkcje i możliwości aplikacji. Nie przechodź na tryb demo bez takiej zgody.

Jak ponownie zgłosić aplikację lub odwołać się od odrzucenia 2.1?

Aby ponownie zgłosić aplikację po odrzuceniu 2.1, wgraj lub wybierz przetestowany build, odpowiedz App Review w App Store Connect, opisując zmiany, zaktualizuj notatki dla recenzenta i zgłoś ponownie. Odwołuj się tylko wtedy, gdy uważasz, że recenzent źle zrozumiał aplikację.

1. Sprawdź, czy numer buildu przypisany do wersji w App Store Connect zgadza się z przetestowanym buildem z TestFlight.
2. Odpowiedz na komunikat o odrzuceniu krótkim podsumowaniem każdej poprawki. W przypadku problemu z zakupem lub nawigacją dodaj instrukcję krok po kroku i zrzuty ekranu.
3. Zaktualizuj sekcję App Review Information o aktualne dane logowania i notatki.
4. Zgłoś aplikację do weryfikacji. Według Apple (stan na październik 2026) zazwyczaj rozpatruje ono „co najmniej 50% zgłoszeń w mniej niż 24 godziny i 90% w mniej niż 48 godzin”.

Jeśli uważasz, że Apple się pomyliło, strona App Review pozwala odwołać się do App Review Board. Podaj konkretne powody, dla których aplikacja spełnia wymagania, i „złóż tylko jedno odwołanie na każde zgłoszenie, które nie przeszło weryfikacji”. Przy odrzuceniu 2.1 odtworzenie problemu na czystym urządzeniu jest jednak zwykle szybsze niż spór. Jeśli wolisz przekazać ponowne zgłoszenie komuś innemu, nasza usługa publikacji w App Store obejmuje przygotowanie do weryfikacji i obsługę uwag po odrzuceniu w obu sklepach za $599, a opłaty za konto deweloperskie są osobne.

Problemy z 2.1 często wracają w kolejnych aktualizacjach: nowa feature flaga, zmieniony klucz API albo wygasłe konto demo. Dodaj ten plan testów do swojej rutyny wydawniczej obok listy kontrolnej publikacji w App Store. Przy aktualizacjach wydanie etapowe ogranicza liczbę użytkowników, do których trafi przeoczony błąd. Aby uzyskać drugą opinię na temat odrzuconego buildu, wyślij e-mail z treścią komunikatu o odrzuceniu na adres yagyeshsrbobde@gmail.com.