Mobiele app checklist voor startups: 34 punten van MVP tot App Store-goedkeuring (2026)

Mobiele app checklist voor startups: 34 punten van MVP tot App Store-goedkeuring (2026)

Apples App Store Review Guideline 5.1.1(v) heeft meer lanceerdata van startups geschrapt dan welke bug die we ooit hebben opgeleverd. Eén ontbrekende accountverwijderknop, ingediend de avond vóór een demo day, en de hele tijdlijn schuift een week op. Deze mobiele app checklist voor startups bestaat omdat die fout volledig te voorkomen is, en bijna niemand het richtlijnnummer opschrijft dat hem veroorzaakt.

Belangrijkste punten:

• Apple wijst apps af vanwege ontbrekende accountverwijderflows en links naar het privacybeleid: richtlijnen 5.1.1 en 1.5 noemen het exact.
• Google Play vereist zowel een in-app als een openbare web-route voor accountverwijdering, met handhaving na de verlengingsdeadline van 31 mei 2024.
• De indienchecklists voor iOS en Android verschillen; ze behandelen als één gecombineerde lijst is de belangrijkste oorzaak van last-minute lanceervertragingen.

Voordat je code schrijft

Voordat er ook maar één scherm ontworpen wordt, moeten drie dingen vastliggen: wat je MVP daadwerkelijk is, of je een privacybeleid nodig hebt (dat heb je), en of de GDPR of de Turkse KVKK van toepassing is op je gebruikers. Deze fase overslaan is waarom founders in de week dat ze wilden indienen alsnog juridische pagina's zitten te schrijven.

Een MVP is, in één zin, de kleinste versie van je product die je kernaanname test bij echte gebruikers. Het is geen uitgeklede versie van je volledige visie. Als de scope nog vaag is, bespaart je build goed afbakenen voordat je één regel code schrijft je het schrappen van features midden in de bouw in plaats van ervoor.

Apples eigen richtlijnen zijn bot over de privacybeleid-eis: Guideline 5.1.1(i) bepaalt dat apps "een link naar hun privacybeleid moeten bevatten" in de App Store Connect-metadata en in veel gevallen ook in de app zelf. Dat is geen suggestie. Als hij ontbreekt, blokkeert het je indiening.

• Definieer je MVP-scope in één zin
• Bevestig dat je een privacybeleid nodig hebt (dat is bijna altijd zo)
• Stel een Support-URL op (Apple Guideline 1.5 vereist het)
• Controleer GDPR/KVKK-toepasbaarheid als je EU- of Turkse gebruikers hebt
• Kies native vs. cross-platform stack

De MVP-bouwweek

Een MVP-bouwweek is waar je beslist wat er daadwerkelijk scheep gaat versus wat geschrapt wordt, en het eerlijke antwoord is: meer dan founders verwachten. Analytics en crashrapportage gaan erin tijdens de bouw, niet erna. Ze achteraf inbouwen betekent dat je precies die data mist waarmee je je eerste aanname had kunnen valideren.

Wat we in de praktijk meestal uit een v1-scope schrappen, is alles wat niet het ene ding is dat getest wordt. Pushnotificaties, social login, een instellingenscherm met zes schakelaars: het kan allemaal wachten. Founders verzetten zich daar begrijpelijkerwijs tegen; het voelt als iets onafgemaakt opleveren. Het is onafgemaakt. Dat is precies de bedoeling.

Zoals een founder die meerdere apps heeft opgeleverd het verwoordde in een dev.to-checklistpost: een feedbackmechanisme vroeg overslaan is een fout waar hij "elke keer spijt van had". Bouw het nu in, niet nadat je eerste review binnenkomt. Wil je het scopegesprek zelf versnellen, dan is AI gebruiken om sneller te scopen het bekijken waard voordat de bouw begint.

• Instrumenteer analytics vóór je eerste TestFlight-/interne build
• Koppel crashrapportage (Sentry of Firebase Crashlytics)
• Bouw een feedbackmechanisme in de app
• Schrap elke feature die niet kern is voor het ene ding dat je test
• Schrijf je eerste versiestring (zie versiebeheer hieronder)

De week voordat je indient

Dit is de fase die elke concurrent-checklist volledig overslaat, en hier gebeuren de meeste voorkombare vertragingen. Semantisch versioneren van apps volgt een MAJOR.MINOR.BUILD-patroon (1.0.0, dan 1.0.1 voor een patch, 1.1.0 voor een feature-bump). Kies nu een schema, want inconsistente versienummers verwarren zowel de appstores als je eigen team.

Een gefaseerde uitrol brengt je update eerst naar een klein percentage gebruikers (vaak 1%, dan 10%, dan 50%) voordat hij naar iedereen gaat. Slechts één van de drie concurrent-checklists die we bekeken noemt het, en dan nog terloops. Als een crash erdoorheen glipt, beperkt een gefaseerde uitrol de schade in plaats van 100% van de gebruikers tegelijk te raken.

De vragen die we stellen voordat we een client-indiening goedkeuren zijn simpel: werkt het kritieke pad nu, end-to-end, op een echt apparaat? Niet de simulator. Is het crashvrije percentage acceptabel? Zijn de store-listing-assets echt definitief, geen placeholders?

• Bevestig dat je versienummer een consistent schema volgt
• Test je kritieke pad nog één keer end-to-end
• Bereid je gefaseerde-uitrolpercentage voor als de store het ondersteunt
• Bevestig dat het crashvrije percentage acceptabel is vóór het indienen
• Maak screenshots en bereid alle store-listing-assets voor

Indieningsdag: iOS vs. Android

iOS- en Android-indieningen falen om verschillende redenen, en ze behandelen als één gecombineerde checklist is veruit de grootste oorzaak van last-minute lanceervertragingen die we zien. Apples App Store Review Guidelines en Googles Play-ontwikkelaarsbeleid noemen elk specifieke, controleerbare eisen, en de meeste founders komen er pas achter na een afwijzingsmail.

In onze eigen app-indieningen zijn de twee dingen die first-time founders het vaakst laten struikelen de accountverwijder-eis en een onbereikbare Support-URL. Beide zijn met één regel op te lossen als je ze vóór het indienen vangt. Beide veroorzaken een automatische afwijzing als je dat niet doet.

Apples App Store Review Guidelines zijn specifiek: Guideline 5.1.1(v) vereist dat apps die accountcreatie ondersteunen ook accountverwijdering in de app aanbieden, Guideline 1.6 dekt Data Security-openbaarmakingen, en Guideline 1.5 vereist een werkende Support-URL. Op Android vereist Googles Play-ontwikkelaarsbeleid zowel een verwijderpad in de app als een openbare web-URL voor accountverwijderverzoeken. Google kondigde de eis aan in april 2023, stelde 7 december 2023 als deadline voor de dataverwijderingsvragen in het Data safety-formulier, en stond verlenging tot 31 mei 2024 toe; daarna krijgen niet-conforme apps te maken met handhaving. Dit is geen oude regel die voor kleine apps is afgeschaft; hij geldt nog steeds.

De twee indienflows verschillen ook mechanisch, niet alleen op papier. Op iOS upload je een build via Xcode of Transporter, verwerkt App Store Connect hem (dat duurt van een paar minuten tot meer dan een uur), en van daaruit stuur je hem naar TestFlight voor interne en externe testers of dien je hem direct in voor App Review. TestFlight is geen optioneel drukwerk: zo verwacht Apple dat je de bugs vangt waarvoor een reviewer je anders zou afwijzen. Op Android werkt Google Play Console met tracks in plaats van één indiening: van intern testen naar gesloten of open testen, dan productie, elk met een eigen publiek en een eigen promotiestap. Een gefaseerde uitrol verschijnt pas als je een bestaande productierelease updatet. Zoals Googles eigen releasedocumentatie het zegt: "als je je eerste release uitrolt, zie je de optie om een uitrolpercentage te kiezen niet", dus plan je allereerste lancering niet rond een percentage-opschaling; die komt later.

Formulieren, geen code, blokkeren de meeste eerste indieningen. Apple vereist een privacy manifest voor een gedefinieerde lijst van veelgebruikte third-party SDK's (advertentienetwerken, analytics, crashrapportage), en hun eigen begeleiding is bot over wie verantwoordelijk is: "wanneer je een third-party SDK met je app gebruikt, ben je verantwoordelijk voor alle code die de SDK in je app opneemt, en moet je op de hoogte zijn van de praktijken voor dataverzameling en -gebruik", aldus Apples third-party SDK-vereistenpagina. Sla een manifest voor een SDK op de lijst over en je build komt niet door App Store Connect. Googles equivalente formulierenpoort is het Data safety-formulier, en het is verplicht voor elke app in elke track, behalve builds die alleen intern testen: "alle ontwikkelaars die een app op Google Play hebben gepubliceerd, moeten het Data safety-formulier invullen, inclusief apps in gesloten, open of productietesttracks", aldus Googles Data safety-documentatie. Vul het verkeerd in en Google zegt ronduit dat het "passende maatregelen kan nemen, inclusief handhavingsmaatregelen" zodra er een mismatch tussen je gedeclareerde en werkelijke app-gedrag opduikt.

Er is een derde faalmodus die niets met beleidstekst te maken heeft: de reviewer kan je app lettert niet testen. Apples Guideline 2.1 zegt het rechtstreeks: "voeg demo-accountinformatie toe (en zet je backend-service aan!) als je app een login bevat". Geen werkende demo-inloggegevens, geen live backend tijdens de reviewperiode, geen bereikbare Support-URL, en je wordt teruggestuurd ongeacht hoe conform je accountverwijderflow is. Als een deel van je app achter een paywall of login zit, schrijf dan reviewer-notities die precies uitleggen hoe je erbij komt. Het is een stap van twee minuten die first-time founders voortdurend overslaan.

Nog een Android-only-poort hoort in hetzelfde rijtje: het target API-niveau. Androids eigen ontwikkelaarsdocumentatie stelt dat "nieuwe apps en app-updates het huidige vereiste Android API-niveau moeten targeten" om ingediend te kunnen worden op Google Play, en dat "verouderde apps niet beschikbaar zijn voor nieuwe gebruikers van apparaten met nieuwere Android-versies". Het heeft niets te maken met accountverwijdering of Data Safety, maar het blokkeert een indiening net zo hard, en het is het soort eis dat elk jaar verschuift, dus controleer het huidige nummer voordat je je release bouwt.

Geen enkele top-checklist voor precies deze zoekopdracht citeert één App Store-richtlijnnummer. Wij wel, want gokken op compliance is hoe lanceringen week voor week vertragen. Als je je bredere datahouding opbouwt, dekt je datahandling-checklist vóór de lancering de beveiligingskant die we hier niet herhalen.

iOS-indienchecklist:

• Privacybeleid-URL live en bereikbaar
• Accountverwijderpad in de app opgeleverd (Guideline 5.1.1(v))
• Support-URL live (Guideline 1.5)
• Data Security-openbaarmakingen ingevuld (Guideline 1.6)
• TestFlight-build goedgekeurd vóór openbare indiening

Android-indienchecklist:

• Data Safety-formulier ingevuld in Play Console
• Accountverwijderpad in de app opgeleverd
• Openbare web-URL voor accountverwijderverzoeken live (Google Play-eis)
• Gefaseerde-uitrolpercentage ingesteld
• Target API-niveau voldoet aan de huidige Play-eis

Lanceerdag

Lanceerdag is de dag dat je app daadwerkelijk live gaat voor echte gebruikers, los van de indiening, die dagen of weken eerder kan plaatsvinden, en los van week één, die de nasleep is. Monitoring van je gefaseerde uitrol op dag één vertelt je of je blijft uitbreiden of op pauze drukt.

Houd je App Store Connect- of Play Console-dashboard het eerste etmaal per uur in de gaten, niet per dag. Als je crashvrije percentage daalt, wil je het binnen het uur weten, niet de volgende ochtend wanneer honderd extra gebruikers dezelfde bug hebben geraakt. Houd een rollback-build klaar. Dezelfde harden-stabilize-deploy-discipline die we voor AI-features gebruiken geldt hier net zo goed.

• Monitor het crashvrije percentage elk uur in de eerste 24 uur
• Zorg dat je supportkanaal bemand en klaar is
• Bevestig dat je gefaseerde uitrol uitbreidt zoals gepland
• Houd een rollback-build klaar voor een kritieke bug

Je eerste week live

De eerste week live is waar het meeste echte werk gebeurt, ook al plant bijna niemand erop. Dagelijkse crashrapport-review en reageren op je eerste store-reviews zijn belangrijker dan alles wat je op lanceerdag zelf deed.

"De lancering zelf maakt minder uit dan je denkt. Waar het om gaat is wat je in de weken erna doet", zoals een founder schreef in zijn eigen post-launch-checklist. Dat is de eerlijke versie van week één: snel patchen, persoonlijk reageren, en daadwerkelijk controleren of je dataverwijderflow werkt voordat een echte gebruiker hem voor je test. Als je je nu afvraagt wat dit allemaal kost om te bouwen en te onderhouden: budgetteren voor post-launch onderhoud en updates is het begeleidende stuk. Deze post gaat over paraatheid; die over de rekening.

• Review crashrapporten dagelijks in de eerste week
• Reageer persoonlijk op je eerste 10 store-reviews
• Triëer en patch elke kritieke bug binnen 48 uur
• Bevestig dat je dataverwijderverzoekproces echt end-to-end werkt
• Stel een ritme in om analytics te toetsen aan je oorspronkelijke MVP-hypothese

Hoe Techsy dit aanpakt

We behandelen de pre-submission review bij elke client-build hetzelfde: voordat we een indiening goedkeuren, vragen we of het kritieke pad werkt op een echt apparaat, of het crashvrije percentage standhoudt, en of elke door de richtlijn verplichte flow (accountverwijdering, privacybeleid, Support-URL) daadwerkelijk functioneert, niet alleen bestaat in een mockup. Het is een korte lijst, maar het is de lijst die bepaalt of een app in één keer door de review komt.

Als je liever iemand hebt die deze richtlijnen eerder heeft doorlopen je indiening laat doen: ons mobiele-app-ontwikkelproces is precies rond deze pre-submission-reviewstap gebouwd. Het vervangt niet je eigen huiswerk; het is wat wij doen nadat jij het gedaan hebt.

Veelgestelde vragen

Wat is een MVP en waarom maakt het uit voor een lancering-checklist?

Een MVP is de kleinste versie van je product die één kernaanname test bij echte gebruikers. Het maakt hier uit omdat elk punt op deze checklist meeschaalt met de scope: een strakkere MVP betekent minder dingen die mis kunnen gaan bij de indiening en minder features om te instrumenteren, monitoren en patchen in week één.

Waarom worden apps afgewezen uit de App Store?

De meest voorkomende voorkombare redenen zijn ontbrekende links naar het privacybeleid (Guideline 5.1.1(i)), geen accountverwijdering in de app (Guideline 5.1.1(v)) en een onbereikbare Support-URL (Guideline 1.5). Geen daarvan vereist engineering-inspanning om op te lossen; het zijn checklistpunten, geen bugs.

Wat gebeurt er als ik geen accountverwijderoptie aan mijn app toevoeg?

Op iOS maakt Guideline 5.1.1(v) dit een automatische afwijzingsreden als je app accountcreatie ondersteunt. Op Android vereist Google Play zowel een verwijderpad in de app als een openbaar web-pad, waarbij niet-conforme apps handhaving riskeren na de verlengingsdeadline van 31 mei 2024; weglaten blokkeert de indiening op beide platforms.

Hebben startups een privacybeleid nodig voor een mobiele app?

Ja, bijna altijd. Apple vereist een gelinkt privacybeleid onder Guideline 5.1.1(i), en Google Play vereist er een in het Data Safety-formulier. Als je ook maar gebruikersdata verzamelt, zelfs alleen een e-mail voor aanmelding, heb je er een nodig vóór het indienen.

Wat is het verschil tussen indienen bij de App Store vs. Google Play?

Apples review is richtlijngedreven met genoemde clausules (5.1.1, 1.5, 1.6) en een menselijke reviewer; Google Play leunt op het Data Safety-formulier en geautomatiseerde controles. De accountverwijder-eis lijkt in opzet maar verschilt in mechanica; zie de vergelijkingstabel hierboven.

Hoe lang duurt een app-store-review echt?

Geen van beide stores publiceert een gegarandeerde doorlooptijd, dus beschouw elk getal dat je leest als een ruwe verwachting, geen belofte. Bij onze eigen client-indieningen kwamen Apple-goedkeuringen meestal binnen een dag of twee binnen, waarbij alles rond accountverwijdering of data-openbaarmaking langer duurde. Google Play was meestal sneller. Plan je lanceerdatum in beide gevallen met speling.

Wat is een gefaseerde uitrol en moet ik die gebruiken?

Een gefaseerde uitrol brengt een update eerst naar een klein percentage gebruikers en breidt daarna geleidelijk uit, in plaats van in één keer naar 100%. Gebruik er een wanneer de store het ondersteunt; hij beperkt hoeveel gebruikers een bug raken voordat je kunt pauzeren en herstellen.

Heb ik een Support-URL nodig om mijn app in te dienen?

Ja. Apples Guideline 1.5 vereist een werkende Support-URL als onderdeel van de indiening, en Google Play verwacht ook een supportcontact. Een dode link of een ongelezen inbox hier is een makkelijke, voorkombare afwijzingsreden.

Wat moet ik monitoren in de eerste week dat mijn app live is?

Crashrapporten dagelijks, je eerste tien store-reviews, en of je dataverwijderverzoekproces echt end-to-end werkt. Dit is ook het moment waarop je echte gebruiksdata begint te toetsen aan de aanname waarvoor je MVP gebouwd is.

Zijn de GDPR of KVKK relevant voor de app van een kleine startup?

Als je gebruikers in de EU hebt, geldt de GDPR ongeacht de grootte van je bedrijf. Als je gebruikers in Turkije hebt, geldt de KVKK op dezelfde manier. Geen van beide wetten kent een vrijstelling voor kleine startups, dus controleer de toepasbaarheid tijdens het scopen, niet nadat je echte gebruikersdata hebt om te beschermen.

Conclusie

Een mobiele app checklist voor startups verdient zijn plek alleen als hij specifiek genoeg is om vandaag op te handelen: definieer je MVP in één zin, instrumenteer analytics vóór de bouw, review je versieschema de week vóór de indiening, en splits je iOS- en Android-checklists in plaats van ze als één lijst te behandelen. Alleen al de accountverwijder- en privacybeleid-punten verklaren de meeste van de vermijdbare afwijzingen die we zien.

Print de checklist, doorloop hem fase voor fase, en sla de eerste week live niet over; dat is het deel dat elke concurrent-checklist weglaat, en het deel dat daadwerkelijk bepaalt of je lancering beklijft. Wil je liever een tweede paar ogen op je indiening voordat je hem verstuurt, vraag een gratis consult aan →