Checklista aplikacji mobilnej dla startupów: 34 punkty od MVP do akceptacji w App Store (2026)

Checklista aplikacji mobilnej dla startupów: 34 punkty od MVP do akceptacji w App Store (2026)

Wytyczna App Store Review Guideline 5.1.1(v) zepsuła więcej dat launchów startupów niż jakikolwiek bug, który kiedykolwiek wypuściliśmy. Jeden brakujący przycisk usunięcia konta, zgłoszony wieczorem przed demo dayem, przesuwa cały harmonogram o tydzień. Ta checklista aplikacji mobilnej dla startupów powstała, bo temu błędowi da się w całości uniknąć, a prawie nikt nie zapisuje numeru wytycznej, która go powoduje.

Najważniejsze wnioski:

• Apple odrzuca aplikacje za brak procesu usunięcia konta i linku do polityki prywatności: wytyczne 5.1.1 i 1.5 nazywają to wprost.
• Google Play wymaga zarówno ścieżki usunięcia konta w aplikacji, jak i publicznej ścieżki webowej, a egzekwowanie nastąpiło po terminie przedłużenia z 31 maja 2024.
• Checklisty zgłoszenia dla iOS i Androida różnią się; traktowanie ich jako jednej wspólnej listy to przyczyna numer 1 opóźnień launchu w ostatniej chwili.

Zanim napiszesz kod

Zanim zaprojektujesz pierwszy ekran, trzeba domknąć trzy rzeczy: czym właściwie jest Twoje MVP, czy potrzebujesz polityki prywatności (tak, potrzebujesz) oraz czy Twoich użytkowników dotyczy RODO, czy tureckie KVKK. Pominięcie tego etapu to powód, dla którego founderzy w panice piszą strony prawne w tygodniu, w którym chcieli zgłaszać aplikację.

MVP to, w jednym zdaniu, najmniejsza wersja produktu, która testuje Twoje główne założenie na prawdziwych użytkownikach. To nie jest okrojona wersja pełnej wizji. Jeśli zakres wciąż jest rozmyty, właściwe określenie zakresu projektu przed napisaniem pierwszej linijki kodu oszczędzi Ci wycinania funkcji w trakcie budowy zamiast przed nią.

Własne wytyczne Apple mówią o wymogu polityki prywatności bez ogródek: wytyczna 5.1.1(i) stanowi, że aplikacje „muszą zawierać link do polityki prywatności" w metadanych App Store Connect, a w wielu przypadkach także w samej aplikacji. To nie jest sugestia. Brak linku blokuje zgłoszenie.

• Zdefiniuj zakres MVP jednym zdaniem
• Potwierdź, że potrzebujesz polityki prywatności (prawie zawsze tak)
• Przygotuj URL pomocy (wytyczna Apple 1.5 go wymaga)
• Sprawdź zastosowanie RODO/KVKK, jeśli masz użytkowników z UE lub Turcji
• Zdecyduj: stack natywny czy cross-platformowy

Tydzień budowania MVP

Tydzień budowania MVP to moment, w którym decydujesz, co faktycznie trafi do wydania, a co zostanie wycięte, i szczera odpowiedź brzmi: więcej, niż founderzy się spodziewają. Analityka i raportowanie crashy wchodzą w trakcie budowy, nie po niej. Dorabianie ich po launchu oznacza utratę dokładnie tych danych, których potrzebowałeś do zweryfikowania pierwszego założenia.

Z zakresu v1 wycinamy najczęściej wszystko, co nie jest tą jedną testowaną rzeczą. Powiadomienia push, logowanie społecznościowe, ekran ustawień z sześcioma przełącznikami, to wszystko może poczekać. Founderzy się przed tym bronią, co zrozumiałe; to uczucie wypuszczania czegoś niedokończonego. To jest niedokończone. O to właśnie chodzi.

Jak ujął to jeden z founderów, który wydał kilka aplikacji, w poście z checklistą na dev.to: pominięcie mechanizmu feedbacku na wczesnym etapie to błąd, którego „żałował za każdym razem". Wbuduj go teraz, nie po pierwszej recenzji. Jeśli chcesz przyspieszyć samą rozmowę o zakresie, przyspieszanie określania zakresu z AI warto przeczytać przed startem budowy.

• Zinstrumentalizuj analitykę przed pierwszym buildem TestFlight/wewnętrznym
• Podepnij raportowanie crashy (Sentry lub Firebase Crashlytics)
• Wbuduj w aplikację mechanizm feedbacku
• Wytnij każdą funkcję, która nie jest rdzeniem testowanej rzeczy
• Zapisz pierwszy ciąg wersji (patrz: wersjonowanie niżej)

Tydzień przed zgłoszeniem

To etap, który każda konkurencyjna checklista całkowicie pomija, a to tu zdarza się najwięcej opóźnień, którym można zapobiec. Wersjonowanie semantyczne aplikacji stosuje schemat MAJOR.MINOR.BUILD (1.0.0, potem 1.0.1 dla patcha, 1.1.0 dla nowej funkcji). Wybierz schemat teraz, bo niespójne numery wersji mylą zarówno sklepy z aplikacjami, jak i Twój własny zespół.

Etapowe wdrażanie (staged rollout) udostępnia aktualizację najpierw małemu odsetkowi użytkowników (często 1%, potem 10%, potem 50%), zanim trafi do wszystkich. Wspomina o tym tylko jedna z trzech przejrzanych przez nas checklist konkurencji, i to mimochodem. Jeśli crash się prześliźnie, etapowe wdrażanie ogranicza promień rażenia zamiast uderzać w 100% użytkowników naraz.

Pytania, które zadajemy przed zielonym światłem dla zgłoszenia klienta, są proste: czy ścieżka krytyczna działa od końca do końca, teraz, na prawdziwym urządzeniu? Nie w symulatorze. Czy odsetek sesji bez crashy jest akceptowalny? Czy materiały do karty w sklepie są naprawdę finalne, a nie zastępcze?

• Potwierdź, że numer wersji trzyma się spójnego schematu
• Przetestuj ścieżkę krytyczną od końca do końca jeszcze raz
• Przygotuj procent etapowego wdrażania, jeśli sklep je obsługuje
• Potwierdź akceptowalny odsetek sesji bez crashy przed zgłoszeniem
• Zrób zrzuty ekranu i przygotuj wszystkie materiały do karty w sklepie

Dzień zgłoszenia: iOS kontra Android

Zgłoszenia na iOS i Androida odpadają z różnych powodów, a traktowanie ich jako jednej wspólnej checklisty to pojedyncza największa przyczyna opóźnień launchu w ostatniej chwili, jakie widzimy. Wytyczne App Store Review Guidelines i zasady deweloperskie Google Play wymieniają konkretne, sprawdzalne wymagania, a większość founderów dowiaduje się o nich dopiero z maila z odrzuceniem.

W naszych własnych zgłoszeniach dwie rzeczy najczęściej potykają początkujących founderów: wymóg usunięcia konta i niedziałający URL pomocy. Obie to poprawki jednej linijki, jeśli wyłapiesz je przed zgłoszeniem. Obie powodują automatyczne odrzucenie, jeśli tego nie zrobisz.

Wytyczne App Store Review Guidelines Apple są konkretne: wytyczna 5.1.1(v) wymaga, by aplikacje obsługujące tworzenie konta oferowały też usunięcie konta w aplikacji, wytyczna 1.6 obejmuje ujawnienia Data Security, a wytyczna 1.5 wymaga działającego URL pomocy. Na Androidzie zasady deweloperskie Google Play wymagają zarówno ścieżki usunięcia w aplikacji, JAK i publicznego URL-a webowego do żądań usunięcia konta. Google ogłosiło ten wymóg w kwietniu 2023, ustaliło termin 7 grudnia 2023 dla pytań o usuwanie danych w formularzu Data Safety i pozwoliło na przedłużenie do 31 maja 2024, po którym aplikacje niespełniające wymogów spotykają sankcje. To nie jest stary przepis, z którego zwolniono małe aplikacje; nadal obowiązuje.

Dwa procesy zgłoszenia różnią się też mechanicznie, nie tylko na papierze. Na iOS wgrywasz build przez Xcode lub Transporter, App Store Connect go przetwarza (trwa to od kilku minut do ponad godziny), a stąd kierujesz go do TestFlight dla testerów wewnętrznych i zewnętrznych albo zgłaszasz bezpośrednio do App Review. TestFlight to nie jest opcjonalna biurokracja: tak Apple oczekuje, że wyłapiesz bugi, za które recenzent i tak by Cię odrzucił. Na Androidzie Google Play Console działa w torach zamiast pojedynczego zgłoszenia: testy wewnętrzne, potem testy zamknięte lub otwarte, potem produkcja, każdy z własną publicznością i własnym krokiem promocji. Etapowe wdrażanie pojawia się dopiero przy aktualizowaniu istniejącego wydania produkcyjnego. Jak ujmuje to własna dokumentacja wydawnicza Google: „jeśli wdrażasz swoje pierwsze wydanie, nie zobaczysz opcji wyboru procentu wdrażania", więc nie planuj pierwszego launchu wokół rampy procentowej, to przychodzi później.

Papierologia, nie kod, blokuje większość pierwszych zgłoszeń. Apple wymaga manifestu prywatności dla określonej listy powszechnie używanych SDK-ów firm trzecich (sieci reklamowe, analityka, raportowanie crashy), a własne wytyczne mówią bez ogródek, kto za to odpowiada: „gdy używasz w aplikacji SDK firmy trzeciej, odpowiadasz za cały kod, który SDK zawiera w Twojej aplikacji, i musisz znać jego praktyki zbierania i wykorzystywania danych", zgodnie ze stroną wymagań Apple dot. SDK firm trzecich. Pomiń manifest dla SDK z listy, a Twój build nie przejdzie App Store Connect. Odpowiednikiem tej papierologii w Google Play jest formularz Data Safety, obowiązkowy dla każdej aplikacji w każdym torze poza buildami wyłącznie do testów wewnętrznych: „wszyscy deweloperzy, którzy mają aplikację opublikowaną w Google Play, muszą wypełnić formularz Data Safety, dotyczy to też aplikacji w torach testów zamkniętych, otwartych i produkcyjnych", według dokumentacji Data Safety Google Play. Wypełnij go źle, a Google mówi wprost, że „może podjąć odpowiednie działania, w tym działania egzekucyjne", gdy wyjdzie na jaw rozbieżność między zadeklarowanym a faktycznym zachowaniem aplikacji.

Jest jeszcze trzeci tryb awarii, który nie ma nic wspólnego z treścią zasad: recenzent dosłownie nie może przetestować Twojej aplikacji. Wytyczna Apple 2.1 mówi to wprost: „dołącz dane konta demo (i włącz swój backend!), jeśli Twoja aplikacja zawiera logowanie". Brak działających danych logowania dla recenzenta, nieżyjący backend w oknie recenzji, niedostępny URL pomocy, i dostaniesz zwrot niezależnie od tego, jak zgodny jest Twój proces usunięcia konta. Jeśli jakakolwiek część aplikacji siedzi za paywallem lub bramką logowania, napisz notatki dla recenzenta wyjaśniające dokładnie, jak tam dotrzeć. To dwuminutowy krok, który początkujący founderzy notorycznie pomijają.

Jeszcze jedna bramka tylko dla Androida należy do tej samej rozmowy: docelowy poziom API. Własna dokumentacja deweloperska Androida stwierdza, że „nowe aplikacje i aktualizacje aplikacji muszą celować" w aktualnie wymagany poziom API Androida, „aby można je było zgłosić do Google Play", oraz że „nieaktualne aplikacje są niedostępne dla nowych użytkowników urządzeń z nowszymi wersjami Androida". Nie ma to nic wspólnego z usuwaniem konta ani Data Safety, ale blokuje zgłoszenie równie stanowczo, i jest to wymóg, który zmienia się co roku, więc sprawdź aktualną liczbę przed zbudowaniem wydania.

Żadna z checklist będących najwyżej w rankingu dla tego zapytania nie cytuje ani jednego numeru wytycznych App Store. My tak, bo zgadywanie w kwestiach zgodności to sposób, w jaki launche przesuwają się o tydzień za każdym razem. Jeśli budujesz szerszą postawę obsługi danych, checklista obsługi danych przed launchem pokrywa stronę bezpieczeństwa, której tu nie duplikujemy.

Checklista zgłoszenia na iOS:

• URL polityki prywatności żywy i osiągalny
• Dostarczona ścieżka usunięcia konta w aplikacji (wytyczna 5.1.1(v))
• Żywy URL pomocy (wytyczna 1.5)
• Wypełnione ujawnienia Data Security (wytyczna 1.6)
• Build TestFlight zatwierdzony przed publicznym zgłoszeniem

Checklista zgłoszenia na Androida:

• Wypełniony formularz Data Safety w Play Console
• Dostarczona ścieżka usunięcia konta w aplikacji
• Żywy publiczny URL webowy do żądań usunięcia konta (wymóg Google Play)
• Ustawiony procent etapowego wdrażania
• Docelowy poziom API spełnia aktualny wymóg Play

Dzień launchu

Dzień launchu to dzień, w którym Twoja aplikacja faktycznie trafia do prawdziwych użytkowników, oddzielony od zgłoszenia, które mogło nastąpić dni lub tygodnie wcześniej, i od pierwszego tygodnia, który jest następstwem. Monitorowanie etapowego wdrażania pierwszego dnia mówi Ci, czy dalej rozszerzać, czy wcisnąć pauzę.

Przez pierwsze 24 godziny obserwuj pulpit App Store Connect lub Play Console co godzinę, nie codziennie. Jeśli odsetek sesji bez crashy spada, chcesz wiedzieć w ciągu godziny, nie następnego ranka, gdy setka kolejnych użytkowników trafiła w ten sam bug. Trzymaj w pogotowiu build do rollbacku. Ta sama dyscyplina hartuj-stabilizuj-wdrażaj, którą stosujemy do funkcji AI, sprawdza się tu równie bezpośrednio.

• Monitoruj odsetek sesji bez crashy co godzinę przez pierwsze 24 godziny
• Miej obsadzony i gotowy kanał pomocy
• Potwierdź, że etapowe wdrażanie rozszerza się zgodnie z planem
• Trzymaj w pogotowiu build do rollbacku na wypadek krytycznego buga

Pierwszy tydzień po launchu

Pierwszy tydzień po launchu to moment, w którym dzieje się większość prawdziwej pracy, choć prawie nikt go nie planuje. Codzienny przegląd raportów o crashach i odpowiadanie na pierwsze recenzje w sklepie znaczą więcej niż cokolwiek, co zrobiłeś w dniu launchu.

„Sam launch znaczy mniej, niż myślisz. Liczy się to, co robisz w kolejnych tygodniach", jak napisał jeden z founderów we własnej checkliście po launchu. To jest szczera wersja pierwszego tygodnia: patchuj szybko, odpowiadaj osobiście i naprawdę sprawdź, że Twój proces usuwania danych działa, zanim przetestuje go na Tobie prawdziwy użytkownik. Jeśli teraz zastanawiasz się, ile to wszystko kosztuje w budowie i utrzymaniu, budżetowanie utrzymania i aktualizacji po launchu to artykuł towarzyszący. Ten post pokrywa gotowość; tamten pokrywa rachunek.

• Przeglądaj raporty o crashach codziennie przez pierwszy tydzień
• Odpowiedz osobiście na pierwszych 10 recenzji w sklepie
• Triaguj i patchuj każdy krytyczny bug w ciągu 48 godzin
• Potwierdź, że proces żądań usunięcia danych naprawdę działa od końca do końca
• Ustal rytm sprawdzania analityki względem pierwotnej hipotezy MVP

Jak podchodzi do tego Techsy

Recenzję przed zgłoszeniem traktujemy tak samo przy każdym buildzie klienta: zanim damy zielone światło, pytamy, czy ścieżka krytyczna działa na prawdziwym urządzeniu, czy odsetek sesji bez crashy się utrzymuje i czy każdy proces nakazany wytycznymi (usunięcie konta, polityka prywatności, URL pomocy) faktycznie działa, a nie tylko istnieje na makiecie. To krótka lista, ale to ta lista decyduje, czy aplikacja przechodzi recenzję za pierwszym razem.

Jeśli wolisz, by Twoje zgłoszenie poprowadził ktoś, kto już przez te wytyczne przeszedł: nasz proces tworzenia aplikacji mobilnych jest zbudowany dokładnie wokół tego kroku przeglądu przed zgłoszeniem. To nie jest zamiennik odrobienia własnej pracy domowej, to coś, co robimy, gdy Ty już ją odrobiłeś.

Często zadawane pytania

Czym jest MVP i dlaczego ma znaczenie w checkliście launchu?

MVP to najmniejsza wersja produktu, która testuje jedno główne założenie na prawdziwych użytkownikach. Ma tu znaczenie, bo każdy punkt tej checklisty skaluje się z zakresem: ciaśniejsze MVP oznacza mniej rzeczy, które mogą pójść nie tak przy zgłoszeniu, i mniej funkcji do zinstrumentalizowania, monitorowania i patchowania w pierwszym tygodniu.

Dlaczego aplikacje są odrzucane w App Store?

Najczęstsze powody, którym można zapobiec, to brak linku do polityki prywatności (wytyczna 5.1.1(i)), brak usunięcia konta w aplikacji (wytyczna 5.1.1(v)) i niedziałający URL pomocy (wytyczna 1.5). Żaden z nich nie wymaga wysiłku inżynierskiego do naprawy, to punkty checklisty, nie bugi.

Co się stanie, jeśli nie dodam opcji usunięcia konta do aplikacji?

Na iOS wytyczna 5.1.1(v) czyni z tego powód automatycznego odrzucenia, jeśli Twoja aplikacja obsługuje tworzenie konta. Na Androidzie Google Play wymaga zarówno ścieżki usunięcia w aplikacji, jak i publicznej ścieżki webowej, a aplikacje niespełniające wymogów spotykają sankcje po terminie przedłużenia z 31 maja 2024; pominięcie tego blokuje zgłoszenie na obu platformach.

Czy startup potrzebuje polityki prywatności do aplikacji mobilnej?

Tak, prawie zawsze. Apple wymaga podlinkowanej polityki prywatności na mocy wytycznej 5.1.1(i), a Google Play wymaga jej w formularzu Data Safety. Jeśli zbierasz jakiekolwiek dane użytkownika, choćby e-mail do rejestracji, potrzebujesz jej przed zgłoszeniem.

Jaka jest różnica między zgłoszeniem do App Store a Google Play?

Recenzja Apple jest napędzana wytycznymi z nazwanymi klauzulami (5.1.1, 1.5, 1.6) i ludzkim recenzentem; Google Play opiera się na formularzu Data Safety i kontrolach automatycznych. Wymóg usunięcia konta jest podobny w duchu, ale różni się mechaniką; patrz tabela porównawcza wyżej.

Ile naprawdę trwa weryfikacja w sklepie z aplikacjami?

Żaden sklep nie publikuje gwarantowanego czasu realizacji, więc każdą liczbę, którą przeczytasz, traktuj jako zgrubne oczekiwanie, a nie obietnicę. W naszych własnych zgłoszeniach klientów akceptacje Apple przychodziły zwykle w ciągu dnia lub dwóch, a wszystko dotykające usunięcia konta lub ujawniania danych trwało dłużej. Google Play był zwykle szybszy. Tak czy inaczej, planuj datę launchu z zapasem.

Czym jest etapowe wdrażanie i czy warto je stosować?

Etapowe wdrażanie udostępnia aktualizację najpierw małemu odsetkowi użytkowników, a potem stopniowo rozszerza, zamiast trafiać do 100% naraz. Stosuj je zawsze, gdy sklep je obsługuje; ogranicza liczbę użytkowników, którzy trafią w bug, zanim zdążysz zatrzymać i naprawić.

Czy do zgłoszenia aplikacji potrzebny jest URL pomocy?

Tak. Wytyczna Apple 1.5 wymaga działającego URL pomocy jako części zgłoszenia, a Google Play również oczekuje kontaktu pomocy. Martwy link lub niemonitorowana skrzynka to łatwy, możliwy do uniknięcia powód odrzucenia.

Co monitorować w pierwszym tygodniu po launchu aplikacji?

Raporty o crashach codziennie, pierwszych dziesięć recenzji w sklepie oraz to, czy Twój proces żądań usunięcia danych naprawdę działa od końca do końca. To także moment, w którym zaczynasz konfrontować prawdziwe dane o użyciu z założeniem, do którego testowania powstało Twoje MVP.

Czy RODO lub KVKK dotyczą aplikacji małego startupu?

Jeśli masz użytkowników w UE, RODO stosuje się niezależnie od wielkości firmy. Jeśli masz użytkowników w Turcji, KVKK stosuje się tak samo. Żadne z tych praw nie ma zwolnienia dla małych startupów, więc sprawdź zastosowanie na etapie określania zakresu, nie gdy masz już prawdziwe dane użytkowników do ochrony.

O autorze

Mert Batur jest współzałożycielem Techsy.io, gdzie zespół dostarcza agentów AI, systemy automatyzacji i pipeline'y głosowe/SDR dla klientów B2B. Pisze o stosie narzędzi LLM, którego zespół Techsy faktycznie używa w produkcji. Połącz się na LinkedIn.

Podsumowanie

Checklista aplikacji mobilnej dla startupów zasługuje na swoje miejsce tylko wtedy, gdy jest dość konkretna, by działać dziś: zdefiniuj MVP jednym zdaniem, zinstrumentalizuj analitykę przed budową, przejrzyj schemat wersjonowania w tygodniu przed zgłoszeniem i rozdziel checklisty iOS oraz Androida zamiast traktować je jako jedną listę. Same punkty usunięcia konta i polityki prywatności odpowiadają za większość możliwych do uniknięcia odrzuceń, które widzimy.

Wydrukuj checklistę, przerabiaj ją etap po etapie i nie pomijaj pierwszego tygodnia po launchu, bo to część, którą każda konkurencyjna checklista pomija, i ta, która naprawdę decyduje, czy Twój launch się utrzyma. Jeśli wolisz drugą parę oczu przy zgłoszeniu przed wysłaniem, umów się na bezpłatną konsultację →