Checklista publikacji w App Store (2026): od buildu w Xcode 26 do Submit for Review

Checklista publikacji w App Store to lista rzeczy, które muszą być gotowe jednocześnie, zanim wyślesz aplikację: działający build, rzetelny opis w sklepie, zgodne z prawdą odpowiedzi o prywatności oraz wystarczający kontekst, aby recenzent mógł korzystać z aplikacji. Sam zielony build nie wystarczy. Sześć poniższych sekcji odpowiada kolejności, w jakiej App Store Connect o nie prosi, a każda zaczyna się od krótkiej odpowiedzi, na podstawie której możesz od razu działać.

Czego potrzebuje zgłoszenie do App Store, zanim klikniesz Submit?

Zgłoszenie do App Store wymaga przetworzonego buildu przypisanego do wersji, wymaganych metadanych wersji, zrzutów ekranu, polityki prywatności, danych kontaktowych dla App Review oraz — jeśli aplikacja ma logowanie — działających danych logowania do konta demo. Lista „Before You Submit” w App Review Guidelines Apple dodaje jeszcze dwa punkty: „Włącz usługi backendowe, aby były aktywne i dostępne podczas recenzji” oraz wyjaśnij w notatkach dla recenzenta funkcje, które nie są oczywiste.

Jakie ustawienia konta i rekordu aplikacji muszą być gotowe?

Potrzebujesz aktywnego członkostwa w Apple Developer, rekordu aplikacji, którego bundle ID zgadza się z podpisanym buildem, oraz osoby w zespole z rolą Account Holder, Admin lub App Manager. Właśnie tych ról wymaga strona Apple Submit an app do wysyłania zgłoszeń.

Podczas tworzenia rekordu wybierz nazwę, język podstawowy i SKU. SKU jest identyfikatorem wewnętrznym i klienci nigdy go nie widzą. Jeśli sprzedajesz płatną aplikację lub zakupy w aplikacji, najpierw dokończ umowy dotyczące płatnych aplikacji oraz dane podatkowe i bankowe. Niepodpisana umowa może wstrzymać komercyjną premierę, nawet jeśli build jest w porządku.

Jakie wymagania dotyczą buildów przesyłanych do App Store w 2026 roku?

Według stanu na październik 2026 r. strona Apple z nadchodzącymi wymaganiami mówi, że „aplikacje przesyłane do App Store Connect muszą być zbudowane w Xcode 26 lub nowszym z użyciem SDK dla iOS 26, iPadOS 26, tvOS 26, visionOS 26 lub watchOS 26” (od 28 kwietnia 2026 r.). Podaje też, że aplikacje na iOS i iPadOS „muszą być przeznaczone dla iOS 13 lub nowszego” (od 9 września 2026 r.).

• Zwiększaj numer buildu przy każdym przesłaniu i upewnij się, że numer wersji odpowiada wydaniu, które chcesz opublikować.
• Zaktualizuj obraz Xcode w CI (Codemagic, Expo EAS, GitHub Actions itd.), a nie tylko na własnym komputerze.
• Po przetworzeniu odpowiedz na ewentualne pytanie o zgodność eksportową i przypisz przetworzony build do wersji.
• Zainstaluj build z TestFlight na fizycznym urządzeniu. Przetestuj onboarding, logowanie, stany offline, zakupy i przywracanie zakupów. Działanie w symulatorze nie dowodzi, że dystrybuowany build działa.
• Przeczytaj e-mail, który App Store Connect wysyła po przesłaniu. Zignorowane ostrzeżenia ITMS dotyczące manifestów prywatności lub wersji SDK zamieniają się w blokery.

Wytyczna 2.1(a) bez ogródek mówi, co się stanie w przeciwnym razie: „Odrzucimy niekompletne pakiety aplikacji i pliki binarne, które się zawieszają lub mają oczywiste problemy techniczne”. Przed archiwizacją usuń ekrany zastępcze, menu debugowania i martwe linki. Nasz plan testów buildu wydaniowego pod wytyczną 2.1 szczegółowo omawia te kontrole.

Jakich zrzutów ekranu i metadanych wymaga App Store Connect?

Według stanu na październik 2026 r. specyfikacja zrzutów ekranu Apple wymaga co najmniej jednego zrzutu dla „iPhone’a z Dynamic Island (średni wyświetlacz)”, na przykład 1206 × 2622 lub 1179 × 2556 w orientacji pionowej. Aplikacje działające na iPadzie potrzebują też co najmniej jednego zrzutu dla iPada 13-calowego, np. 2064 × 2752 lub 2048 × 2732.

Możesz „przesłać do 10 zrzutów ekranu na każdy rozmiar urządzenia w formatach .jpeg, .jpg lub .png”, a „obrazy nie mogą zawierać kanałów alfa ani przezroczystości”. Jeśli interfejs jest taki sam we wszystkich rozmiarach, prześlij tylko najwyższą wymaganą rozdzielczość, a App Store Connect ją przeskaluje. Wytyczna 2.3.3 mówi, że zrzuty ekranu „powinny pokazywać aplikację w użyciu, a nie wyłącznie grafikę tytułową, ekran logowania czy ekran powitalny”.

• Napisz opis, który mówi, dla kogo jest aplikacja i co można w niej zrobić podczas pierwszej sesji.
• Dbaj o trafność nazwy, podtytułu i słów kluczowych. Nie powtarzaj słów kluczowych i nie używaj nazw konkurentów.
• Upewnij się, że URL wsparcia i URL polityki prywatności otwierają się bez logowania.
• Wypełnij kwestionariusz klasyfikacji wiekowej na podstawie tego, co aplikacja faktycznie zawiera i umożliwia.
• Pokaż na zrzutach ekranu aktualny build, łącznie z paywallem, na który trafi użytkownik.

Jak sprawić, by odpowiedzi o prywatności zgadzały się z aplikacją?

Aby odpowiedzi o prywatności zgadzały się z aplikacją, spisz każde dołączone SDK i dane, które zbiera, a następnie na podstawie tej listy wypełnij sekcję App Privacy, napisz politykę prywatności i skonfiguruj zachowanie w aplikacji. Wytyczna 2.3 mówi, że metadane, „w tym informacje o prywatności”, muszą rzetelnie odzwierciedlać aplikację.

Wytyczna 5.1.1(i) stanowi: „Wszystkie aplikacje muszą zawierać link do polityki prywatności w polu metadanych App Store Connect oraz w samej aplikacji, w łatwo dostępnym miejscu”. Wytyczna 5.1.1(v) dodaje: „Jeśli aplikacja umożliwia założenie konta, musisz również zapewnić możliwość usunięcia konta w aplikacji”. SDK do analityki, raportowania awarii, reklam i logowania zwykle zmieniają Twoje odpowiedzi, więc sprawdź je z pomocą naszego audytu SDK pod etykiety prywatności. Sprawdź też, czy Twoja aplikacja i każde dołączone SDK zawierają manifest prywatności PrivacyInfo.xcprivacy, który obejmuje wszystkie używane przez nie API typu required-reason.

Co powinna zawierać sekcja App Review Information?

Sekcja App Review Information powinna zawierać osobę kontaktową, która odpowie, dane logowania do konta demo, które działają i nie wygasają, oraz notatki prowadzące recenzenta prosto do kluczowych funkcji. Wytyczna 2.1(a) prosi, aby „dołączyć dane konta demo (i włączyć usługę backendową!), jeśli aplikacja ma logowanie”; wbudowany tryb demo zamiast konta wymaga wcześniejszej zgody Apple.

Oto przykładowe notatki dla recenzenta: „Zaloguj się na dostarczone konto do recenzji. Otwórz Bibliotekę, wybierz przykładowy projekt i stuknij Eksportuj. Konto ma odblokowane wszystkie funkcje premium. Funkcje lokalizacji korzystają z symulowanego miasta, więc nie trzeba nigdzie jechać”. Nie odsyłaj recenzentów do pustego konta, jednorazowego kodu, który wygasa, ani do procesu, który działa tylko wtedy, gdy jesteś online i możesz go zatwierdzić. Nasz poradnik konfiguracji konta demo pokazuje, jak przygotować logowanie dla recenzenta, które się nie posypie.

Jak wysłać aplikację do recenzji w App Store Connect?

Aby wysłać aplikację do recenzji, przypisz build do wersji, kliknij Add for Review, a następnie Submit for Review. Samo Add for Review niczego nie wysyła do Apple. Poniższa kolejność odpowiada stronie Apple „Submit an app” według stanu na październik 2026 r.

1. W sekcji Apps wybierz aplikację, a następnie kliknij wersję aplikacji na pasku bocznym.
2. Przewiń do sekcji Build i potwierdź, że przypisany jest właściwy build.
3. W sekcji App Store Version Release wybierz wydanie ręczne, jeśli chcesz kontrolować dzień premiery, a następnie kliknij Save.
4. Kliknij Add for Review i wybierz istniejące zgłoszenie robocze lub utwórz nowe. Status zmieni się na Ready for Review.
5. Kliknij Submit for Review. Gdy recenzja się rozpocznie, status zmieni się na In Review.
6. Zachowaj kopię wysłanych metadanych i notatek oraz obserwuj skrzynkę e-mail kontaktu do recenzji, czekając na ewentualne pytania.

Jeśli zgłoszenie wróci odrzucone, przeczytaj numer wytycznej i wyjaśnienie recenzenta, zanim cokolwiek zmienisz. Niektóre poprawki dotyczą wyłącznie metadanych. Inne wymagają nowego buildu. Nasz poradnik o odrzuceniach w App Store pokazuje, jak rozpoznać, z którym przypadkiem masz do czynienia.

Co poszło nie tak innym deweloperom przy wysyłaniu zgłoszenia?

W obu opisanych poniżej publicznych przypadkach aplikacja działała u dewelopera, a problem ujawnił się dopiero w przesłanym buildzie lub podczas pierwszej sesji recenzenta.

Deweloper na forum Adalo otrzymał odrzucenie z wytycznej 2.1: „nie udało nam się zalogować przy użyciu podanych danych konta demo”. Dane logowania były prawidłowe, ale pierwsze stuknięcie przycisku logowania nic nie robiło i działało dopiero drugie, ponieważ nawigacja warunkowa uruchamiała się na przycisku logowania, zanim sesja użytkownika została zarejestrowana. Naprawił to, kierując przycisk logowania na pusty ekran przejściowy, który zawierał akcje warunkowe, a następnie ponownie wysłał zgłoszenie.

Deweloper na forum JUCE po przesłaniu buildu otrzymał komunikat „ITMS-91053: Missing API declaration” informujący, że nowe przesyłki „muszą zawierać tablicę NSPrivacyAccessedAPITypes w manifeście prywatności aplikacji”. Wskazane kategorie to SystemBootTime i FileTimestamp, a inny użytkownik zgłosił UserDefaults. Rozwiązaniem był plik PrivacyInfo.xcprivacy z zatwierdzonymi kodami powodów, dodany jako zasób w Xcode. W pierwszej wersji jednego z użytkowników zabrakło klucza typu, co wywołało ITMS-91056 dla nieprawidłowego manifestu, dopóki go nie poprawił.

Obaj deweloperzy testowali tylko na własnym środowisku. Zanim klikniesz Submit for Review, przetestuj build, który faktycznie otrzymuje Apple, logując się od zera, i przeczytaj każdy e-mail wysłany po przesłaniu. Jeśli chcesz, żeby ktoś jeszcze rzucił okiem na całość, zobacz nasze usługi związane z publikacją.