Google Play Console: je eerste app publiceren

Het uploaden van je app is zelden het probleem. De drempel zit ervoor: heb je je ontwikkelaarsaccount op persoonlijke naam aangemaakt na 13 november 2023, dan eist Google eerst een gesloten test met minimaal 12 testers die 14 aaneengesloten dagen ingeschreven blijven, voordat je productietoegang mag aanvragen. Organisatie-accounts vallen daar niet onder. Hieronder staat hoe die eis werkt en welke formulieren je daarnaast langs moet.

Terug naar OneDayBuild
01 / 07

De eis die de meeste founders overvalt

Je app is af, je account staat klaar, en dan blijkt de weg naar productie afgesloten tot je een testfase hebt doorlopen.

Sinds november 2023 behandelt Google nieuwe persoonlijke ontwikkelaarsaccounts anders dan zakelijke. Is jouw account als particulier aangemaakt na 13 november 2023, dan moet je eerst een gesloten test draaien met minimaal 12 testers die de afgelopen 14 dagen onafgebroken ingeschreven stonden. Pas daarna verschijnt de knop om productietoegang aan te vragen.

Dat aantal is een keer bijgesteld: aanvankelijk 20 testers, eind 2024 verlaagd naar 12. Wees dus voorzichtig met wat je hierover leest, want veel artikelen noemen nog het oude getal en de regel kan opnieuw wijzigen. Leidend is de officiële Play Console-documentatie over testvereisten.

Belangrijker dan het getal is het mechanisme. Google wil dat een onbekende ontwikkelaar aantoont dat echte mensen met de app hebben gewerkt. De aanvraag is dan ook geen vinkje, maar een vragenlijst over je testers en hun feedback.

02 / 07

Internal, closed en open testing

Drie testsporen die op elkaar lijken, terwijl er maar één meetelt voor de verplichte testfase.

Internal testing

Voor je eigen kring, per e-mailadres toegevoegd. Builds komen hier het snelst beschikbaar omdat dit spoor niet dezelfde beoordeling doorloopt. Handig om te zien of je build op echte toestellen start, maar het telt niet mee voor de verplichte testfase.

Closed testing

Een besloten test met een genodigdenlijst uit e-mailadressen of een Google Groep. Dit spoor doorloopt wel de normale beoordeling, en hier gaat de eis van 12 testers over. Het knelpunt is nooit de limiet, maar het vinden van deelnemers die meedoen.

Open testing

Iedereen kan zich aanmelden via je vermelding in de Play Store, die daarmee zichtbaar wordt. Nuttig om breder te testen, maar geen shortcut om de gesloten test over te slaan.

03 / 07

Twaalf testers regelen is het echte werk

Niet omdat twaalf mensen veel is, maar omdat ze twee weken ingeschreven moeten blijven en de app ook echt moeten openen.

  • Uitgenodigd is niet ingeschreven. Iemand telt pas mee als hij de uitnodiging accepteert en installeert onder precies het account waarop je hem uitnodigde. Dit is het meest voorkomende struikelblok: accepteren met het ene adres, installeren met het andere.
  • Ingeschreven is niet gebruikt. Installeren en nooit openen vult je teller, maar Google kijkt bij de beoordeling naar hoe actief de groep was. Een stille test is een zwakke aanvraag.
  • De periode loopt door, in aaneengesloten dagen. Vraag deelnemers de app te laten staan tot je het sein geeft.
  • Ruilgroepen leveren aantallen, geen inzicht. Je haalt het minimum wel, maar je aanvraag draait om feedback van mensen die je product echt zouden gebruiken.
  • Werf ruimer dan het minimum, want er valt altijd iemand af.

Dit is dus geen technische stap maar een wervingsklus. Denk aan je eerste klanten, je netwerk of mensen op je wachtlijst. Hoe je die groep vindt staat in betatesters vinden voor je app, en hoe je er bruikbare informatie uit haalt in je app laten testen met gebruikers.

04 / 07

Data safety, classificatie en de rest van de papieren

Formulieren die je snel invult en later duur betaalt als je antwoorden niet kloppen met wat je app doet.

Het Data safety-formulier is verplicht voor elke app die op Google Play staat, dus ook tijdens je gesloten test. Je verklaart welke gegevens je verzamelt, welke je deelt, waarvoor, en of gebruikers verwijdering kunnen aanvragen. De valkuil zit in wat je niet zelf schreef: libraries voor analytics, crashrapportage, advertenties en inloggen sturen data naar buiten, en dat melden is jouw verantwoordelijkheid. Klopt je verklaring niet met het gedrag van de app, dan kan Google handhaven. Een privacybeleid is verplicht om het formulier af te ronden; zie ook de AVG-checklist voor een nieuwe app.

De contentclassificatie loopt via een vragenlijst over de inhoud: geweld, seksualiteit, gokken, interactie tussen gebruikers. Daaruit volgt per regio een leeftijdsclassificatie. Vul je hem niet in, dan blijft je app ongeclassificeerd en dat is een reden voor verwijdering. Antwoord eerlijk: een classificatie die niet klopt is erger dan een hogere leeftijdsgrens.

Tot slot een technische eis die vaak wordt gemist: je app moet een recente Android-versie als doel hebben. Google schuift die grens elk jaar op. Welke versie nu geldt staat in Google's overzicht van de doel-API-eisen. Bouw je met AI-tools of oudere sjablonen, controleer dit expliciet.

05 / 07

App-signing: wie houdt de sleutel vast

Een administratief ogend onderwerp met een harde consequentie: de verkeerde sleutel kwijtraken betekent dat je je app niet meer kunt bijwerken.

Android controleert bij elke update of de nieuwe versie met dezelfde sleutel is ondertekend als de vorige. Vroeger beheerde je die sleutel zelf, en een verloren keystore betekende het einde van de app: geen update meer mogelijk, opnieuw beginnen zonder je bestaande gebruikers.

Nieuwe apps gaan daarom via Play App Signing, waarbij Google de definitieve ondertekeningssleutel beheert. Jij houdt een upload-sleutel om je bestanden aan te leveren. Het verschil telt: raak je je upload-sleutel kwijt, dan vraag je een reset aan en kun je verder. Beheer je de ondertekeningssleutel zelf en raak je die kwijt, dan is er geen weg terug.

Regel daarom nu al twee dingen. Bewaar je upload-keystore en wachtwoord buiten je codeopslag, op een plek waar je ze over twee jaar nog vindt. En laat je de app bouwen, leg dan vast dat het account en de sleutels op jouw naam staan.

06 / 07

Naar productie, en waarin Apple verschilt

De release zelf is een handeling van een paar minuten. De beoordeling eromheen bepaalt of die handeling ergens toe leidt.

Is je testfase rond, dan dien je een aanvraag voor productietoegang in: geschreven antwoorden over de test, over je app en doelgroep, en over waarom het product klaar is voor publiek. Die vragen worden gelezen. Een concreet voorbeeld van feedback en wat je daarop veranderde is meer waard dan algemene zinnen.

Daarna volgt de release: je kiest de landen, schrijft release-notities, kunt eerst aan een deel van de gebruikers uitrollen en dient de versie in ter beoordeling. Hoe lang die beoordeling duurt ligt niet vast.

Bij Apple ligt de wrijving op een ander punt. Daar zit de rem aan het eind: een menselijke beoordelaar bekijkt de complete app en kan hem afwijzen op inhoud, ontwerp of beleidsregels, waarna je aanpast en opnieuw indient. Bij Google is die laatste stap doorgaans lichter, maar staat er voor een nieuw persoonlijk account juist een poort vóór de indiening. Hoe het aan de Apple-kant loopt staat in je app in de App Store zetten en in app afgewezen in de App Store; het account zelf komt aan bod in een Apple developer-account aanvragen.

07 / 07

Veelgestelde vragen

Geldt de verplichte testfase ook voor mij?

Die geldt voor persoonlijke ontwikkelaarsaccounts aangemaakt na 13 november 2023: minimaal 12 testers, 14 aaneengesloten dagen ingeschreven, voordat je productietoegang kunt aanvragen. Organisatie-accounts en oudere persoonlijke accounts niet. Controleer de actuele eis in de officiële Play Console-documentatie, want de regel is al eens aangepast.

Wat betekent 14 dagen aaneengesloten ingeschreven?

Dat je testers die hele periode onafgebroken deelnemen, niet in losse blokken. Iemand telt pas mee als hij de uitnodiging accepteerde en de app installeerde onder hetzelfde Google-account waarop hij is uitgenodigd. Vraag deelnemers dus om de app te laten staan tot je het sein geeft.

Telt internal testing mee voor de verplichte testfase?

Nee, de eis gaat expliciet over een gesloten test. Internal testing brengt snel een build bij je eigen kring en doorloopt niet dezelfde beoordeling. Nuttig om te zien of je build op echte toestellen werkt, maar het brengt je niet dichter bij productietoegang.

Kan ik de eis omzeilen met een organisatie-account?

Organisatie-accounts vallen er niet onder, maar het is geen trucje: je moet een echte, geregistreerde organisatie zijn en die identiteit laten verifiëren. Kies het accounttype dat bij je situatie past, want het type zet je achteraf niet even om.

Moet ik het Data safety-formulier invullen?

Ja, voor elke app die op Google Play gepubliceerd staat, inclusief je gesloten en open test. Je verklaart welke gegevens je verzamelt en deelt, waarvoor, en of gebruikers verwijdering kunnen vragen. Vergeet niet wat libraries voor analytics, advertenties en inloggen versturen.

Wat gebeurt er als ik mijn sleutel kwijtraak?

Dat hangt van de sleutel af. Raak je je upload-sleutel kwijt, dan vraag je een reset aan en kun je verder, omdat Google de definitieve ondertekeningssleutel beheert. Beheer je die sleutel zelf en raak je hem kwijt, dan kun je je app niet meer bijwerken.

Hoe lang duurt het voordat mijn app in de Play Store staat?

Dat is niet te garanderen. Het bestaat uit delen die je niet in de hand hebt: de testperiode, de beoordeling van je aanvraag voor productietoegang en de beoordeling van de release. Plan geen lancering op een datum die van een beoordelaar afhangt.

Eerst weten of je app dit traject waard is?

Publiceren in een store is een traject op zich. Stuur ons je idee, dan leveren we in één werkdag een klikbaar prototype waarmee je de flow kunt toetsen, zodat je weet of het zin heeft om aan dat traject te beginnen.