Checklist mobilní aplikace pro startupy: 34 bodů od MVP po schválení v App Store (2026)

Checklist mobilní aplikace pro startupy: 34 bodů od MVP po schválení v App Store (2026)

Bod 5.1.1(v) směrnice App Store Review Guidelines zabil víc dat spuštění startupů než jakákoli chyba, kterou jsme kdy poslali do produkce. Jedno chybějící tlačítko pro smazání účtu, odeslané večer před demo day, a celý harmonogram sklouzne o týden. Tento checklist mobilní aplikace pro startupy existuje proto, že téhle chybě se dá zcela vyhnout, a přitom si skoro nikdo nezapisuje číslo směrnice, které ji způsobuje.

Klíčové body:

• Apple odmítá aplikace kvůli chybějícímu toku smazání účtu a odkazu na zásady ochrany osobních údajů: směrnice 5.1.1 a 1.5 to říkají přesně.
• Google Play vyžaduje cestu smazání účtu v aplikaci i veřejnou webovou cestu, přičemž vynucování nastupuje po prodloužené lhůtě do 31. května 2024.
• Checklisty pro odeslání do iOS a Androidu se liší; považovat je za jeden sloučený seznam je příčina číslo 1 zpoždění spuštění na poslední chvíli.

Než napíšete první řádek kódu

Než se navrhne první obrazovka, je potřeba upevnit tři věci: co přesně je vaše MVP, jestli potřebujete zásady ochrany osobních údajů (ano, potřebujete), a zda se na vaše uživatele vztahuje GDPR nebo turecký zákon KVKK. Přeskočení této fáze je důvod, proč pak zakladatelé na poslední chvíli sepisují právní stránky v týdnu, kdy chtěli odesílat do obchodu.

MVP je jednou větou nejmenší verze vašeho produktu, která ověří váš klíčový předpoklad na reálných uživatelích. Není to osekaná verze vaší plné vize. Pokud si rozsahem stále nejste jisti, správné vymezení rozsahu buildu ještě před prvním řádkem kódu vás ochrání před škrtáním funkcí uprostřed vývoje místo před ním.

Vlastní směrnice Applu jsou ohledně požadavku na zásady ochrany osobních údajů přímočaré: bod 5.1.1(i) stanovuje, že aplikace „musí obsahovat odkaz na své zásady ochrany osobních údajů" v metadatech App Store Connect a v mnoha případech i přímo v aplikaci. To není doporučení. Pokud odkaz chybí, je to překážka odeslání.

• Definujte rozsah MVP jednou větou
• Potvrďte, že potřebujete zásady ochrany osobních údajů (skoro vždy ano)
• Připravte Support URL (směrnice 1.5 ji vyžaduje)
• Ověřte použitelnost GDPR/KVKK, pokud máte uživatele z EU nebo Turecka
• Rozhodněte o nativním versus multiplatformním stacku

Týden buildu MVP

Týden buildu MVP je okamžik, kdy rozhodujete, co se opravdu odešle a co se škrtne, a upřímná odpověď zní: škrtne se toho víc, než zakladatelé čekají. Analytika a hlášení pádů se zabudují během buildu, ne až po něm. Dodatečná integrace po spuštění znamená, že přijdete přesně o ta data, která jste potřebovali k ověření prvního předpokladu.

Co z rozsahu v1 ve skutečnosti škrtáme, je ve většině případů cokoli, co není tou jednou testovanou věcí. Push notifikace, sociální přihlášení, obrazovka nastavení se šesti přepínači, to vše počká. Zakladatelé se tomu brání, pochopitelně; působí to, jako by odesílali něco nedokončeného. Ono to nedokončené je. To je ten smysl.

Jak to formuloval jeden zakladatel, který vydal několik aplikací, v checklistovém příspěvku na dev.to: vynechat zpětnou vazbu v rané fázi je chyba, které „pokaždé litoval". Zapracujte ji teď, ne až dorazí první recenze. Pokud chcete urychlit samotnou debatu o rozsahu, využití AI pro rychlejší vymezení rozsahu stojí za přečtení ještě před začátkem buildu.

• Zinstrumentujte analytiku před prvním TestFlight/interním buildem
• Zapojte hlášení pádů (Sentry nebo Firebase Crashlytics)
• Zabudujte do aplikace mechanismus zpětné vazby
• Škrtněte každou funkci, která není klíčová pro testovanou věc
• Napište první řetězec verze (viz verzování níže)

Týden před odesláním

Tohle je fáze, kterou konkurenční checklisty úplně přeskakují, a přitom se v ní dějí nejvíc zbytečná zpoždění. Sémantické verzování aplikací se řídí vzorcem MAJOR.MINOR.BUILD (1.0.0, pak 1.0.1 pro opravu, 1.1.0 pro novou funkci). Zvolte si schéma teď, protože nekonzistentní čísla verzí matou oba obchody i váš vlastní tým.

Fázované nasazení (staged rollout) uvolní aktualizaci nejprve malému procentu uživatelů (často 1 %, pak 10 %, pak 50 %), než se dostane ke všem. Zmiňuje ho jen jeden ze tří konkurenčních checklistů, které jsme zkoumali, a i ten jen okrajově. Pokud crash proklouzne, fázované nasazení omezí poloměr dopadu, místo aby zasáhlo 100 % uživatelů naráz.

Otázky, které klademe, než dáme zelenou k odeslání klienta, jsou jednoduché: funguje kritická cesta od začátku do konce, právě teď, na reálném zařízení? Ne v simulátoru. Je míra bezpádovosti přijatelná? Jsou podklady pro stránku v obchodě opravdu finální, ne zástupné?

• Potvrďte, že číslo verze odpovídá konzistentnímu schématu
• Otestujte kritickou cestu od začátku do konce ještě jednou
• Připravte procento fázovaného nasazení, pokud ho obchod podporuje
• Před odesláním potvrďte přijatelnou míru bezpádovosti
• Vyfoťte snímky obrazovky a připravte všechny podklady pro stránku v obchodě

Den odeslání: iOS vs. Android

Odeslání do iOS a Androidu selhávají z různých důvodů a jejich zpracování jako jednoho sloučeného checklistu je zdaleka největší příčinou zpoždění spuštění na poslední chvíli, kterou vídáme. App Store Review Guidelines Applu a vývojářské zásady Google Play každé jmenují konkrétní, zkontrolovatelné požadavky a většina zakladatelů se o nich dozví až z e-mailu o zamítnutí.

Při našich vlastních odesláních aplikací jsou dvě věci, které nejčastěji potrápí prvoodesilatele: požadavek na smazání účtu a nedostupná Support URL. Obojí je oprava na jeden řádek, pokud to zachytíte před odesláním. Obojí způsobí automatické zamítnutí, pokud ne.

Směrnice Applu App Store Review Guidelines jsou konkrétní: bod 5.1.1(v) vyžaduje, aby aplikace podporující vytvoření účtu nabízely i smazání účtu přímo v aplikaci, bod 1.6 pokrývá zveřejnění dat v sekci Data Security a bod 1.5 vyžaduje funkční Support URL. Na Androidu vývojářské zásady Google Play vyžadují cestu smazání v aplikaci A ZÁROVEŇ veřejnou webovou URL pro žádosti o smazání účtu. Google požadavek oznámil v dubnu 2023, stanovil termín 7. prosince 2023 pro otázky ohledně mazání dat ve formuláři Data Safety a umožnil prodloužení do 31. května 2024, po kterém nevyhovujícím aplikacím hrozí vynucení. Nejde o staré pravidlo, ze kterého byly malé aplikace vyňaty; stále platí.

Dva postupy odeslání se liší i mechanicky, ne jen na papíře. Na iOS nahrajete build přes Xcode nebo Transporter, App Store Connect ho zpracuje (což trvá od několika minut po více než hodinu) a odtud ho buď pošlete do TestFlight pro interní a externí testery, nebo odešlete přímo do App Review. TestFlight není volitelná byrokracie: je to způsob, jakým Apple očekává, že zachytíte chyby, kvůli kterým by vás recenzent jinak zamítl. Na Androidu Google Play Console funguje v trackech místo jednoho odeslání, prochází interním testováním, pak uzavřeným nebo otevřeným testováním a pak produkcí, každý s vlastním publikem a vlastním krokem povýšení. Fázované nasazení se objeví, teprve když aktualizujete existující produkční vydání. Jak uvádí vlastní dokumentace Googlu k vydávání: „Pokud nasazujete své první vydání, možnost volby procenta nasazení neuvidíte," takže neplánujte vůbec první spuštění kolem procentního náběhu, ten přichází až později.

Ne kód, ale papírování ve skutečnosti blokuje většinu prvních odeslání. Apple vyžaduje privacy manifest pro definovaný seznam běžně používaných SDK třetích stran (reklamní sítě, analytika, nástroje pro hlášení pádů) a jeho vlastní vyjádření je přímočaré ohledně toho, kdo nese odpovědnost: „když ve své aplikaci používáte SDK třetí strany, nesete odpovědnost za veškerý kód, který SDK do vaší aplikace zahrnuje, a musíte znát jeho postupy sběru a využití dat," uvádí stránka Applu o požadavcích na SDK třetích stran. Pokud manifest pro vypsaný SDK vynecháte, váš build App Store Connect neprojde. Ekvivalentní papírovací brána Google Play je formulář Data Safety a je povinný pro každou aplikaci v každém tracku kromě buildů určených jen pro interní testování: „všichni vývojáři, kteří mají aplikaci publikovanou na Google Play, musí vyplnit formulář Data Safety, včetně aplikací v uzavřených, otevřených nebo produkčních testovacích trackech," uvádí dokumentace Google Play k Data Safety. Pokud ho vyplníte špatně, Google otevřeně říká, že „může přijmout příslušná opatření, včetně vynucovacích," jakmile se objeví rozpor mezi deklarovaným a skutečným chováním aplikace.

Existuje třetí režim selhání, který nemá co do činění s textem zásad: recenzent vaši aplikaci doslova nemůže otestovat. Směrnice Applu 2.1 to říká přímo: „pokud vaše aplikace obsahuje přihlášení, zahrňte údaje demo účtu (a zapněte svou backendovou službu!)". Žádné funkční demo přihlašovací údaje, žádný živý backend během okna posuzování, žádná dostupná Support URL, a budete vráceni bez ohledu na to, jak vyhovující je váš tok smazání účtu. Pokud je jakákoli část aplikace za paywallem nebo přihlášením, napište poznámky pro recenzenta vysvětlující přesně, jak se k ní dostat. Je to dvouminutový krok, který prvoodesilatelé neustále přeskakují.

Ještě jedna brána jen pro Android patří do stejné debaty: cílová úroveň API. Vlastní vývojářská dokumentace Androidu uvádí, že „nové aplikace a aktualizace aplikací musí cílit" na aktuálně vyžadovanou úroveň API Androidu, „aby mohly být odeslány do Google Play," a že „zastaralé aplikace nejsou dostupné novým uživatelům zařízení s novějšími verzemi Androidu." Nemá to nic společného s mazáním účtu ani s Data Safety, ale blokuje to odeslání stejně nekompromisně a je to typ požadavku, který se každý rok posouvá, takže před buildem vydání zkontrolujte aktuální číslo.

Žádný z nejlépe umístěných checklistů pro přesně toto hledání necituje jediné číslo směrnice App Store. My ano, protože odhadování souladu je způsob, jakým se spuštění zdržují o týden. Pokud budujete širší postoj k nakládání s daty, checklist nakládání s daty před spuštěním pokrývá bezpečnostní stranu, kterou tu neduplikujeme.

Checklist pro odeslání do iOS:

• URL zásad ochrany osobních údajů je živá a dostupná
• Cesta smazání účtu v aplikaci je odeslána (směrnice 5.1.1(v))
• Support URL je živá (směrnice 1.5)
• Zveřejnění dat v Data Security je dokončeno (směrnice 1.6)
• Build v TestFlight je schválen před veřejným odesláním

Checklist pro odeslání do Androidu:

• Formulář Data Safety je vyplněn v Play Console
• Cesta smazání účtu v aplikaci je odeslána
• Veřejná webová URL pro žádosti o smazání účtu je živá (požadavek Google Play)
• Procento fázovaného nasazení je nastaveno
• Cílová úroveň API odpovídá aktuálnímu požadavku Play

Den spuštění

Den spuštění je den, kdy se vaše aplikace opravdu zpřístupní reálným uživatelům, odděleně od odeslání, které může proběhnout o dny nebo týdny dříve, a odděleně od prvního týdne, což jsou následky. Sledování fázovaného nasazení první den vám řekne, jestli dál rozšiřovat, nebo zmáčknout pauzu.

Sledujte dashboard App Store Connect nebo Play Console každou hodinu, ne denně, prvních 24 hodin. Pokud míra bezpádovosti klesne, chcete to vědět do hodiny, ne až další ráno, kdy na stejnou chybu narazilo sto dalších uživatelů. Mějte připravený rollback build. Stejná disciplína harden-stabilize-deploy, kterou používáme pro AI funkce, platí stejně přímo i tady.

• Sledujte míru bezpádovosti každou hodinu prvních 24 hodin
• Mějte kanál podpory obsazený a připravený
• Potvrďte, že fázované nasazení se rozšiřuje podle plánu
• Mějte připravený rollback build pro případ kritické chyby

První týden v provozu

První týden v provozu je místo, kde se odehrává většina skutečné práce, i když ho skoro nikdo neplánuje. Denní kontrola hlášení pádů a odpovídání na první recenze v obchodě znamenají víc než cokoli, co jste udělali v den spuštění.

„Samotné spuštění znamená míň, než si myslíte. Záleží na tom, co děláte v týdnech poté," napsal jeden zakladatel ve vlastním checklistu po spuštění. To je upřímná verze prvního týdne: patchujte rychle, odpovídejte osobně a opravdu si ověřte, že váš tok mazání dat funguje, než ho za vás otestuje reálný uživatel. Pokud vás teď zajímá, kolik to vše stojí na vývoji a údržbě, rozpočtování údržby a aktualizací po spuštění je doplňkový článek. Tento příspěvek pokrývá připravenost; ten druhý pokrývá účet.

• Kontrolujte hlášení pádů denně první týden
• Odpovězte osobně na prvních 10 recenzí v obchodě
• Roztřiďte a opravte každou kritickou chybu do 48 hodin
• Potvrďte, že proces žádosti o smazání dat opravdu funguje od začátku do konce
• Nastavte rytmus kontroly analytiky vůči původní hypotéze MVP

Jak k tomu přistupuje Techsy

Předodesílací posouzení řešíme u každého klientského buildu stejně: než dáme odeslání zelenou, ptáme se, jestli kritická cesta funguje na reálném zařízení, jestli drží míra bezpádovosti a jestli každý směrnicí vyžadovaný tok (smazání účtu, zásady ochrany osobních údajů, Support URL) opravdu funguje, ne jen existuje v maketě. Je to krátký seznam, ale je to seznam, který určuje, zda aplikace projde posouzením na první pokus.

Pokud byste radši nechali odeslání na někom, kdo těmito směrnicemi už procházel, náš proces vývoje mobilních aplikací je postavený přesně kolem tohoto kroku předodesílacího posouzení. Není to náhrada vaší vlastní domácí přípravy, je to to, co děláme poté, co ji zvládnete.

Často kladené otázky

Co je MVP a proč je důležité pro checklist spuštění?

MVP je nejmenší verze vašeho produktu, která ověří jeden klíčový předpoklad na reálných uživatelích. Tady je důležité proto, že každá položka tohoto checklistu se škáluje s rozsahem: těsnější MVP znamená míň věcí, které se mohou při odesílání pokazit, a míň funkcí, které se mají instrumentovat, sledovat a patchovat v prvním týdnu.

Proč jsou aplikace zamítány v App Store?

Nejčastější odstranitelné důvody jsou chybějící odkaz na zásady ochrany osobních údajů (směrnice 5.1.1(i)), žádné smazání účtu v aplikaci (směrnice 5.1.1(v)) a nedostupná Support URL (směrnice 1.5). Žádný z nich nevyžaduje inženýrské úsilí na opravu, jsou to položky checklistu, ne chyby.

Co se stane, když do aplikace nepřidám možnost smazání účtu?

Na iOS z toho směrnice 5.1.1(v) dělá automatický důvod zamítnutí, pokud vaše aplikace podporuje vytvoření účtu. Na Androidu Google Play vyžaduje cestu smazání v aplikaci i veřejnou webovou cestu, přičemž nevyhovujícím aplikacím hrozí vynucení po prodloužené lhůtě do 31. května 2024, a její vynechání blokuje odeslání na obou platformách.

Potřebuje startup zásady ochrany osobních údajů pro mobilní aplikaci?

Ano, skoro vždy. Apple vyžaduje odkazované zásady ochrany osobních údajů podle směrnice 5.1.1(i) a Google Play je vyžaduje uvnitř formuláře Data Safety. Pokud sbíráte jakákoli uživatelská data, byť jen e-mail pro registraci, potřebujete je před odesláním.

Jaký je rozdíl mezi odesláním do App Store a Google Play?

Posuzování Applu je řízené směrnicemi s pojmenovanými body (5.1.1, 1.5, 1.6) a lidským recenzentem; Google Play se spoléhá na formulář Data Safety a automatizované kontroly. Požadavek na smazání účtu je podobný v duchu, ale liší se mechanikou; viz srovnávací tabulka výše.

Jak dlouho ve skutečnosti trvá posouzení v obchodě?

Žádný obchod nezveřejňuje garantovanou dobu odezvy, takže jakékoli číslo, které si přečtete, berte jako hrubé očekávání, ne jako slib. Při našich vlastních klientských odesláních schválení od Applu obecně dorazila do jednoho až dvou dnů, přičemž cokoli dotýkající se mazání účtu nebo zveřejnění dat trvalo déle. Google Play byl obvykle rychlejší. Tak či tak plánujte datum spuštění s rezervou.

Co je fázované nasazení a mám ho použít?

Fázované nasazení uvolní aktualizaci nejprve malému procentu uživatelů a pak se postupně rozšiřuje, místo aby šla na 100 % naráz. Použijte ho vždy, když ho obchod podporuje; omezuje počet uživatelů, které zasáhne chyba, než ji můžete pozastavit a opravit.

Potřebuji k odeslání aplikace Support URL?

Ano. Směrnice Applu 1.5 vyžaduje funkční Support URL jako součást odeslání a Google Play rovněž očekává kontakt podpory. Mrtvý odkaz nebo nesledovaná schránka je tady snadný, odstranitelný důvod zamítnutí.

Co sledovat v prvním týdnu aplikace v provozu?

Hlášení pádů denně, prvních deset recenzí v obchodě a to, zda váš proces žádosti o smazání dat opravdu funguje od začátku do konce. Tady také začínáte konfrontovat reálná data o používání s předpokladem, na jehož ověření bylo MVP postavené.

Je GDPR nebo KVKK relevantní pro aplikaci malého startupu?

Pokud máte uživatele v EU, GDPR platí bez ohledu na velikost vaší firmy. Pokud máte uživatele v Turecku, KVKK platí stejně. Žádný ze zákonů nemá výjimku pro malé startupy, takže použitelnost ověřte během vymezování rozsahu, ne až máte reálná uživatelská data, která je třeba chránit.

O autorovi

Mert Batur je spoluzakladatel Techsy.io, kde tým odesílá AI agenty, automatizační systémy a hlasové/SDR pipeline pro B2B klienty. Píše o stacku nástrojů pro LLM, který tým Techsy skutečně používá v produkci. Spojte se na LinkedIn.

Závěr

Checklist mobilní aplikace pro startupy si zaslouží své místo, jen když je dost konkrétní, aby se podle něj dalo jednat ještě dnes: definujte MVP jednou větou, zinstrumentujte analytiku před buildem, zkontrolujte schéma verzování v týdnu před odesláním a rozdělte checklisty pro iOS a Android, místo abyste je zpracovávali jako jeden seznam. Jen položky smazání účtu a zásad ochrany osobních údajů tvoří většinu odstranitelných zamítnutí, která vidíme.

Checklist si vytiskněte, projděte ho fázi po fázi a nepřeskakujte první týden v provozu, to je část, kterou každý konkurenční checklist vynechává, a přitom právě ta rozhoduje o tom, jestli se vaše spuštění udrží. Pokud chcete před odesláním druhý pár očí na svůj build, získejte konzultaci zdarma →