Checklist aplicație mobilă pentru startupuri: 34 de puncte de la MVP la aprobarea App Store (2026)

Checklist aplicație mobilă pentru startupuri: 34 de puncte de la MVP la aprobarea App Store (2026)

Regula 5.1.1(v) din ghidul de revizuire App Store al Apple a omorât mai multe date de lansare ale startupurilor decât orice bug pe care l-am livrat noi vreodată. Un singur buton lipsă de ștergere a contului, trimis cu o seară înainte de demo day, și întregul calendar alunecă cu o săptămână. Acest checklist de aplicație mobilă pentru startupuri există tocmai pentru că greșeala asta poate fi evitată complet, iar aproape nimeni nu notează numărul regulii care o provoacă.

Pe scurt:

• Apple respinge aplicații pentru fluxuri de ștergere a contului și linkuri de politică de confidențialitate lipsă: regulile 5.1.1 și 1.5 le numesc exact.
• Google Play cere atât o cale de ștergere a contului în aplicație, cât și una publică pe web, cu măsuri de aplicare după termenul de extensie din 31 mai 2024.
• Checklist-urile de trimitere pentru iOS și Android diferă; tratarea lor ca o singură listă comună este cauza numărul 1 a întârzierilor de lansare din ultimul moment.

Înainte să scrii cod

Înainte ca un singur ecran să fie proiectat, trei lucruri trebuie blocate: ce este de fapt MVP-ul tău, dacă ai nevoie de o politică de confidențialitate (ai nevoie) și dacă GDPR sau KVKK din Turcia se aplică utilizatorilor tăi. Săritul peste această etapă este motivul pentru care fondatorii ajung să scrie pagini legale în grabă chiar în săptămâna în care voiau să trimită aplicația.

Un MVP, într-o singură propoziție, este cea mai mică versiune a produsului tău care testează presupunerea centrală cu utilizatori reali. Nu este o versiune trunchiată a viziunii tale complete. Dacă încă nu ai claritate asupra scopului, definirea corectă a proiectului înainte de prima linie de cod te salvează de tăierea funcționalităților în mijlocul construcției, în loc de dinaintea ei.

Ghidurile Apple sunt tranșante în privința cerinței de politică de confidențialitate: regula 5.1.1(i) prevede că aplicațiile „trebuie să includă un link către politica lor de confidențialitate" în metadatele din App Store Connect și, în multe cazuri, în aplicația însăși. Nu este o sugestie. Este un blocaj de trimitere dacă lipsește.

• Definește scopul MVP-ului tău într-o singură propoziție
• Confirmă că ai nevoie de o politică de confidențialitate (aproape întotdeauna ai nevoie)
• Pregătește un URL de suport (regula 1.5 Apple îl cere)
• Verifică aplicabilitatea GDPR/KVKK dacă ai utilizatori din UE sau Turcia
• Decide între stack nativ și cross-platform

Săptămâna de construcție a MVP-ului

Săptămâna de construcție a MVP-ului este momentul în care decizi ce ajunge efectiv în producție și ce se taie, iar răspunsul sincer este: mai mult decât se așteaptă fondatorii. Analiticele și raportarea crash-urilor intră în timpul construcției, nu după. Montarea lor după lansare înseamnă că pierzi exact datele de care aveai nevoie pentru a-ți valida prima presupunere.

Ceea ce tăiem de fapt dintr-un scop de v1, de cele mai multe ori, este orice nu reprezintă unicul lucru testat. Notificările push, login-ul social, un ecran de setări cu șase comutatoare, toate pot aștepta. Fondatorii se opun, pe bună dreptate; pare că livrezi ceva neterminat. Chiar este neterminat. Asta este ideea.

După cum a spus un fondator care a lansat mai multe aplicații într-un articol-checklist pe dev.to, săritul peste un mecanism de feedback la început este o greșeală pe care „a regretat-o de fiecare dată". Integrează-l acum, nu după ce sosește prima recenzie. Dacă vrei să accelerezi chiar conversația de definire a scopului, folosirea AI pentru definirea rapidă a scopului merită citită înainte de începerea construcției.

• Instrumentează analiticele înainte de primul build TestFlight/intern
• Montează raportarea crash-urilor (Sentry sau Firebase Crashlytics)
• Construiește un mecanism de feedback în aplicație
• Taie orice funcționalitate care nu este centrală pentru unicul lucru testat
• Scrie primul tău șir de versiune (vezi versionarea mai jos)

Săptămâna de dinaintea trimiterii

Aceasta este etapa pe care orice checklist concurent o sare complet, și aici se întâmplă cele mai prevenibile întârzieri. Versionarea semantică pentru aplicații urmează un tipar MAJOR.MINOR.BUILD (1.0.0, apoi 1.0.1 pentru un patch, 1.1.0 pentru o funcționalitate nouă). Alege o schemă acum, pentru că numerele de versiune inconsistente confundă atât magazinele de aplicații, cât și propria echipă.

Un rollout etapizat lansează actualizarea ta mai întâi către un procent mic de utilizatori (adesea 1%, apoi 10%, apoi 50%) înainte de a ajunge la toată lumea. Doar unul dintre cele trei checklist-uri concurente pe care le-am analizat îl menționează, și acela doar în treacăt. Dacă un crash se strecoară, un rollout etapizat limitează raza de impact în loc să lovească 100% dintre utilizatori deodată.

Întrebările pe care le punem înainte de a aproba trimiterea unui client sunt simple: funcționează calea critică de la un capăt la altul, chiar acum, pe un dispozitiv real? Nu pe simulator. Este acceptabilă rata fără crash? Sunt activele de listare din magazin cu adevărat finale, nu substituenți?

• Confirmă că numărul de versiune urmează o schemă consistentă
• Testează calea critică de la un capăt la altul încă o dată
• Pregătește procentul de rollout etapizat dacă magazinul îl suportă
• Confirmă că rata fără crash este acceptabilă înainte de trimitere
• Capturează și pregătește toate activele de listare în magazin

Ziua trimiterii: iOS vs. Android

Trimiterile iOS și Android eșuează din motive diferite, iar tratarea lor ca un singur checklist comun este cea mai mare cauză a întârzierilor de lansare din ultimul moment pe care le vedem. Ghidurile de revizuire App Store ale Apple și politicile de dezvoltator Google Play numesc fiecare cerințe specifice, verificabile, iar majoritatea fondatorilor află despre ele abia după un e-mail de respingere.

În propriile noastre trimiteri de aplicații, cele două lucruri care îi blochează cel mai des pe fondatorii aflați la prima încercare sunt cerința de ștergere a contului și un URL de suport inaccesibil. Ambele sunt corecturi de un singur rând dacă le prinzi înainte de trimitere. Ambele provoacă o respingere automată dacă nu le prinzi.

Ghidurile de revizuire App Store ale Apple sunt specifice: regula 5.1.1(v) cere ca aplicațiile care suportă crearea de conturi să ofere și ștergerea contului din aplicație, regula 1.6 acoperă dezvăluirile de securitate a datelor, iar regula 1.5 cere un URL de suport funcțional. Pe Android, politica de dezvoltator Google Play cere atât o cale de ștergere în aplicație, cât și un URL web public pentru cererile de ștergere a contului. Google a anunțat cerința în aprilie 2023, a stabilit un termen pe 7 decembrie 2023 pentru întrebările de ștergere a datelor din formularul Data safety și a permis extensii până pe 31 mai 2024, după care aplicațiile neconforme intră sub măsuri de aplicare. Nu este o regulă veche scoasă din uz pentru aplicațiile mici; se aplică în continuare.

Cele două fluxuri de trimitere diferă și mecanic, nu doar pe hârtie. Pe iOS, încarci un build prin Xcode sau Transporter, App Store Connect îl procesează (durează de la câteva minute până la peste o oră), iar de acolo fie îl direcționezi către TestFlight pentru testeri interni și externi, fie îl trimiți direct la App Review. TestFlight nu este muncă opțională de bifat: așa se așteaptă Apple să prinzi bug-urile pentru care un recenzor te-ar respinge. Pe Android, Google Play Console lucrează pe track-uri în locul unei trimiteri unice, trecând prin testare internă, apoi testare closed sau open, apoi producție, fiecare cu publicul și cu pasul propriu de promovare. Un rollout etapizat apare abia când actualizezi o versiune de producție existentă. După cum spune chiar documentația de lansare Google, „dacă lansezi prima versiune, nu vei vedea opțiunea de a selecta un procent de rollout", deci nu-ți planifica prima lansare în jurul unei rampe procentuale; asta vine mai târziu.

Actele, nu codul, sunt cele care blochează de fapt majoritatea trimiterilor făcute pentru prima dată. Apple cere un manifest de confidențialitate pentru o listă definită de SDK-uri terțe utilizate frecvent (rețele de publicitate, analitice, raportare de crash-uri), iar ghidul propriu este tranșant în privința celui responsabil: „când folosești un SDK terț în aplicația ta, ești responsabil pentru tot codul pe care SDK-ul îl include în aplicația ta și trebuie să cunoști practicile lui de colectare și utilizare a datelor", conform paginii Apple de cerințe pentru SDK-uri terțe. Sari peste manifest pentru un SDK din listă și build-ul tău nu trece de App Store Connect. Echivalentul Google Play ca barieră de acte este formularul Data safety, obligatoriu pentru orice aplicație de pe orice track, cu excepția build-urilor doar pentru testare internă: „toți dezvoltatorii care au o aplicație publicată pe Google Play trebuie să completeze formularul Data safety, inclusiv aplicațiile de pe track-urile de testare closed, open sau production", conform documentației Google Play Data safety. Completează-l greșit și Google spune răspicat că „poate lua măsuri adecvate, inclusiv măsuri de aplicare" de îndată ce apare o nepotrivire între comportamentul declarat și cel real al aplicației.

Există un al treilea mod de eșec care nu are nicio legătură cu textul politicilor: recenzorul pur și simplu nu poate testa aplicația ta. Regula 2.1 Apple spune asta direct: „include datele unui cont demo (și pornește serviciul tău back-end!) dacă aplicația ta include un login". Fără credențiale demo funcționale, fără backend live în fereastra de revizuire, fără URL de suport accesibil, vei fi respins indiferent cât de conform este fluxul tău de ștergere a contului. Dacă orice parte a aplicației tale stă în spatele unui paywall sau al unui login, scrie note pentru recenzor care explică exact cum se ajunge acolo. Este un pas de două minute pe care fondatorii la prima lansare îl sar constant.

Încă o barieră specifică Android ține de aceeași conversație: nivelul API țintă. Documentația de dezvoltator Android spune că „aplicațiile noi și actualizările de aplicații trebuie să țintească" nivelul API Android cerut curent „pentru a fi trimise pe Google Play" și că „aplicațiile neactualizate nu sunt disponibile pentru utilizatorii noi ai dispozitivelor care rulează versiuni mai noi de Android". Nu are nicio legătură cu ștergerea contului sau cu Data Safety, dar blochează o trimitere la fel de categoric, și este genul de cerință care se schimbă în fiecare an, deci verifică numărul curent înainte de a-ți construi versiunea.

Zero dintre checklist-urile clasate pe primele locuri pentru exact această căutare citează un singur număr de regulă App Store. Noi o facem, pentru că ghicitul conformității este modul în care lansările întârzie câte o săptămână pe rând. Dacă îți construiești postura mai largă de gestionare a datelor, checklist-ul tău de gestionare a datelor înainte de lansare acoperă latura de securitate pe care nu o duplicăm aici.

Checklist de trimitere iOS:

• URL-ul politicii de confidențialitate live și accesibil
• Calea de ștergere a contului în aplicație livrată (regula 5.1.1(v))
• URL de suport live (regula 1.5)
• Dezvăluirile Data Security completate (regula 1.6)
• Build TestFlight aprobat înainte de trimiterea publică

Checklist de trimitere Android:

• Formularul Data Safety completat în Play Console
• Calea de ștergere a contului în aplicație livrată
• URL web public pentru cererile de ștergere a contului live (cerință Google Play)
• Procentul de rollout etapizat setat
• Nivelul API țintă respectă cerința curentă Play

Ziua lansării

Ziua lansării este ziua în care aplicația ta ajunge efectiv live pentru utilizatori reali, separată de trimitere, care se poate întâmpla cu zile sau săptămâni mai devreme, și separată de prima săptămână, care reprezintă urmările. Monitorizarea rollout-ului etapizat în prima zi este cea care îți spune dacă să continui extinderea sau să apeși pauză.

Urmărește panoul din App Store Connect sau Play Console la fiecare oră, nu zilnic, în primele 24 de ore. Dacă rata fără crash scade, vrei să afli în decurs de o oră, nu a doua zi dimineață, când încă o sută de utilizatori au lovit același bug. Ține un build de rollback pregătit. Aceeași disciplină de consolidare-stabilizare-lansare pe care o folosim pentru funcționalitățile AI se aplică la fel de direct aici.

• Monitorizează rata fără crash la fiecare oră în primele 24 de ore
• Ține canalul de suport acoperit și pregătit
• Confirmă că rollout-ul etapizat se extinde conform planului
• Ține un build de rollback pregătit în caz de bug critic

Prima săptămână live

Prima săptămână live este locul unde se întâmplă cea mai mare parte din munca reală, deși aproape nimeni nu o planifică. Revizuirea zilnică a rapoartelor de crash și răspunsul la primele recenzii din magazin contează mai mult decât orice ai făcut în ziua lansării.

„Lansarea în sine contează mai puțin decât crezi. Ceea ce contează este ce faci în săptămânile de după", după cum a scris un fondator în propriul său checklist post-lansare. Aceasta este versiunea sinceră a primei săptămâni: patch rapid, răspuns personal și verificarea reală a faptului că fluxul de ștergere a datelor funcționează înainte ca un utilizator real să-l testeze pentru tine. Dacă acum te întrebi cât costă toată această construcție și întreținere, bugetarea mentenanței și actualizărilor post-lansare este articolul companion. Acest articol acoperă pregătirea; acela acoperă factura.

• Revizuiește rapoartele de crash zilnic în prima săptămână
• Răspunde personal la primele 10 recenzii din magazin
• Triază și repară orice bug critic în 48 de ore
• Confirmă că procesul de cerere a ștergerii datelor funcționează efectiv de la un capăt la altul
• Stabilește un ritm de verificare a analiticelor față de ipoteza inițială a MVP-ului

Cum abordează Techsy asta

Tratăm revizuirea pre-trimitere la fel pentru fiecare build de client: înainte de a aproba o trimitere, ne întrebăm dacă calea critică funcționează pe un dispozitiv real, dacă rata fără crash se menține și dacă fiecare flux cerut de ghiduri (ștergerea contului, politica de confidențialitate, URL-ul de suport) funcționează efectiv, nu doar există într-un mockup. Este o listă scurtă, dar este lista care determină dacă o aplicație trece de revizuire din prima încercare.

Dacă preferi ca cineva care a mai navigat aceste ghiduri să se ocupe de trimiterea ta, procesul nostru de dezvoltare de aplicații mobile este construit exact în jurul acestui pas de revizuire pre-trimitere. Nu este un înlocuitor pentru temele tale proprii, ci ceea ce facem noi după ce ți le-ai făcut.

Întrebări frecvente

Ce este un MVP și de ce contează pentru un checklist de lansare?

Un MVP este cea mai mică versiune a produsului tău care testează o singură presupunere centrală cu utilizatori reali. Contează aici pentru că fiecare punct din acest checklist scalează cu scopul: un MVP mai strâns înseamnă mai puține lucruri care pot merge prost la trimitere și mai puține funcționalități de instrumentat, monitorizat și reparat în prima săptămână.

De ce sunt respinse aplicațiile din App Store?

Cele mai comune motive prevenibile sunt linkurile lipsă de politică de confidențialitate (regula 5.1.1(i)), lipsa ștergerii contului în aplicație (regula 5.1.1(v)) și un URL de suport inaccesibil (regula 1.5). Niciuna nu necesită efort de inginerie pentru corectare; sunt puncte de checklist, nu bug-uri.

Ce se întâmplă dacă nu adaug o opțiune de ștergere a contului în aplicația mea?

Pe iOS, regula 5.1.1(v) face din asta un motiv automat de respingere dacă aplicația ta suportă crearea de conturi. Pe Android, Google Play cere atât o cale de ștergere în aplicație, cât și una publică pe web, iar aplicațiile neconforme intră sub măsuri de aplicare după termenul de extensie din 31 mai 2024; omiterea ei blochează trimiterea pe ambele platforme.

Au startupurile nevoie de o politică de confidențialitate pentru o aplicație mobilă?

Da, aproape întotdeauna. Apple cere o politică de confidențialitate cu link conform regulii 5.1.1(i), iar Google Play cere una în formularul Data Safety. Dacă colectezi orice date de utilizator, chiar și doar un e-mail pentru înscriere, ai nevoie de ea înainte de trimitere.

Care este diferența dintre trimiterea la App Store și cea la Google Play?

Revizuirea Apple este condusă de ghiduri, cu clauze numite (5.1.1, 1.5, 1.6) și un recenzor uman; Google Play se bazează pe formularul Data Safety și verificări automate. Cerința de ștergere a contului este similară ca spirit, dar diferă ca mecanică; vezi tabelul de comparație de mai sus.

Cât durează de fapt revizuirea în magazinul de aplicații?

Niciun magazin nu publică un termen garantat, deci tratează orice număr citești ca pe o așteptare aproximativă, nu ca pe o promisiune. În propriile noastre trimiteri de client, aprobările Apple au sosit în general în una-două zile, iar orice atinge ștergerea contului sau dezvăluirea datelor durează mai mult. Google Play a fost de obicei mai rapid. Planifică-ți data de lansare cu marjă în orice variantă.

Ce este un rollout etapizat și ar trebui să-l folosesc?

Un rollout etapizat lansează o actualizare mai întâi către un procent mic de utilizatori, apoi se extinde treptat, în loc să ajungă la 100% deodată. Folosește-l ori de câte ori magazinul îl suportă; limitează numărul de utilizatori care lovesc un bug înainte să poți pune pauză și să-l repari.

Am nevoie de un URL de suport pentru a-mi trimite aplicația?

Da. Regula 1.5 Apple cere un URL de suport funcțional ca parte a trimiterii, iar Google Play așteaptă de asemenea un contact de suport. Un link mort sau o inbox nesupravegheată aici este un motiv de respingere ușor și evitabil.

Ce ar trebui să monitorizez în prima săptămână live a aplicației mele?

Rapoartele de crash zilnic, primele zece recenzii din magazin și dacă procesul de cerere a ștergerii datelor funcționează efectiv de la un capăt la altul. Tot acum începi să verifici datele reale de utilizare față de presupunerea pentru testarea căreia a fost construit MVP-ul.

Sunt GDPR sau KVKK relevante pentru aplicația unui startup mic?

Dacă ai utilizatori în UE, GDPR se aplică indiferent de dimensiunea companiei tale. Dacă ai utilizatori în Turcia, KVKK se aplică la fel. Niciuna dintre legi nu are o excepție pentru startupurile mici, deci verifică aplicabilitatea în timpul definirii scopului, nu după ce ai date reale de utilizator de protejat.

Despre autor

Mert Batur este co-fondator al Techsy.io, unde echipa livrează agenți AI, sisteme de automatizare și pipeline-uri voce/SDR pentru clienți B2B. El scrie despre stack-ul de instrumente LLM pe care echipa Techsy îl folosește efectiv în producție. Conectează-te pe LinkedIn.

Concluzie

Un checklist de aplicație mobilă pentru startupuri își câștigă locul doar dacă este suficient de specific pentru a acționa azi: definește MVP-ul într-o propoziție, instrumentează analiticele înainte de construcție, revizuiește schema de versionare în săptămâna de dinaintea trimiterii și separă checklist-urile iOS și Android în loc să le tratezi ca pe o singură listă. Doar punctele de ștergere a contului și politică de confidențialitate reprezintă majoritatea respingerilor evitabile pe care le vedem.

Tipărește checklist-ul, parcurge-l etapă cu etapă și nu sări peste prima săptămână live; aceasta este partea pe care orice checklist concurent o omite și partea care determină efectiv dacă lansarea ta se menține. Dacă preferi o a doua pereche de ochi pe trimiterea ta înainte de a o trimite, primește o consultație gratuită →.