· Publishing · 6 min leestijd

App Store Connect vs Google Play Console: de publicatie-workflow

App Store Connect vs Google Play Console: de publicatie-workflow
TL;DR. Apple beoordeelt een versie — build en metadata samen — en geeft je daarna automatische, handmatige of geplande release, plus een 7-daagse gefaseerde uitrol bij automatische updates. Google beoordeelt een app-release voor een track, houdt store-listing-wijzigingen op een apart spoor, en geeft je managed publishing plus een percentage-gebaseerde staged rollout. Zelfde doel, andere mechaniek. De tabel hieronder is de kaart.

Als je naar één store publiceert, leer je één console en ga je verder. Publiceer je naar beide, dan houd je twee mentale modellen aan die dezelfde woorden gebruiken voor andere dingen. "Release", "review" en "rollout" betekenen in App Store Connect net iets anders dan in Google Play Console. Deze post zet de twee workflows stap voor stap naast elkaar, zodat je een lancering kunt plannen die op beide stores landt zonder verrassingen.

De workflow, naast elkaar

Begin hier. Elke rij is een fase van het live krijgen van een update; de twee kolommen laten zien wat er in elke console daadwerkelijk gebeurt.

Alleen-metadata-wijzigingDe meeste listing-wijzigingen gaan mee met een nieuwe versie door review; slechts een paar velden zijn live te bewerken.Een store-listing-wijziging, ingediend en beoordeeld zonder een nieuwe build te versturen.

Hoe Apple een versie uitbrengt

In App Store Connect is de eenheid van werk een versie. Je koppelt een build, vult de metadata en screenshots in, en dient het geheel in bij App Review. Apple bekijkt het als één pakket — daarom betekent een screenshot-wissel of een tekstaanpassing op zichzelf meestal een nieuwe versie en nog een keer door review.

Zodra App Review goedkeurt, bepaalt je release-optie wat er gebeurt. Kies automatisch en hij gaat meteen live. Kies handmatig en hij blijft geparkeerd op "Pending Developer Release" — Apple heeft goedgekeurd, maar niets is publiek totdat jij op de knop drukt (reken op maximaal 24 uur voordat hij daadwerkelijk verschijnt). Kies gepland en hij verschijnt automatisch op of na een datum en tijd die jij instelt. Je kiest dit per versie, dus elke update is een nieuwe beslissing.

Voor een geleidelijke lancering zet je gefaseerde release aan. Die geldt voor automatische updates bij bestaande gebruikers en verspreidt ze over 7 dagen met oplopend percentage, en je kunt hem pauzeren als iets niet klopt in de cijfers. Hij geldt niet voor een gloednieuwe app en niet voor handmatige releases — dat is het App Store-equivalent van Google's staged rollout, geen rem op de hele release.

Hoe Google naar een track uitbrengt

Google splitst dezelfde klus over tracks. Een build begint op een testtrack — intern, gesloten of open — en wordt gepromoveerd naar productie zodra je zover bent. Interne test is voor een kleine, vertrouwde groep (tot 100). Gesloten test verbreedt naar uitgenodigde lijsten (tot 2.000 per lijst). Open test is publiek op basis van aanmelding, zonder limiet. Productie is iedereen in de landen die je hebt gekozen.

Wanneer je een release pusht, is managed publishing het equivalent van Apple's handmatige release. Staat het aan, dan verzamelen goedgekeurde wijzigingen zich in het Publishing-overzicht onder "changes ready to send" en gaan ze pas live als jij publiceert — handig om een release af te stemmen op een marketingdatum. Staat het uit, dan worden goedgekeurde wijzigingen gepubliceerd zodra de review is afgerond.

Voor een geleidelijke lancering gebruik je een staged rollout: release naar een percentage gebruikers en verhoog dat zelf in de loop van de tijd, met de mogelijkheid te stoppen bij oplopende crashcijfers. Net als Apple's gefaseerde release is dit voor updates, niet voor eerste lanceringen — een gloednieuwe productie-release gaat in één keer naar iedereen.

Het verschil waar mensen over struikelen

Dit is het onderscheid om te onthouden: Apple koppelt metadata aan de versie; Google houdt de store-listing gescheiden van de release.

Bij Apple maken je screenshots, beschrijving en keywords deel uit van de versie die wordt beoordeeld. Wil je de screenshots tussen builds door vernieuwen? Voor de meeste velden betekent dat een nieuwe versie en nog een review-ronde. Bij Google is de store-listing een eigen object — je kunt tekst en beeldmateriaal bijwerken en alleen dát door review sturen, terwijl de uitgebrachte app-bundle precies blijft waar hij is. Twee stores, twee heel verschillende antwoorden op "kan ik dit aanpassen zonder volledige release?"

Dit doet er het meest toe bij een lancering met veel bewegende onderdelen: een build, een screenshot-set, vertaalde tekst voor tientallen markten. Bij Apple batch je dat doorgaans allemaal in één versie zodat het samen wordt beoordeeld. Bij Google kun je de listing en de release onafhankelijk van elkaar klaarzetten en publiceren in welke volgorde het plan ook vereist.

Reviewtijden, en het addertje voor nieuwe accounts

Apple's App Review duurt in 2026 ongeveer 24-48 uur voor een gebruikelijke update, langer voor een eerste indiening van een nieuwe developer of alles wat voor nader onderzoek wordt gemarkeerd. Google's review is vaak sneller — uren tot een paar dagen voor een gevestigd account — maar er is een drempel voor nieuwkomers.

Een persoonlijk Google Play developer-account dat na half november 2023 is aangemaakt, moet een gesloten test draaien met minstens 12 testers die zich hebben aangemeld, gedurende 14 aaneengesloten dagen, voordat het toegang tot productie kan aanvragen. Zak je onder de 12 testers, dan kan de reeks resetten. Organisatie-accounts en oudere persoonlijke accounts slaan dit over. Apple heeft geen direct equivalent, dus als je een eerste app op beide stores lanceert, houd dan rekening met Google's testvenster — dat is meestal de langere adem.

Waar Mokbi past

Beide consoles willen dezelfde afgewerkte assets: geframede screenshots en heldere, vertaalde tekst op elke vereiste maat. Mokbi bouwt dat één keer. Je ontwerpt de screenshots en schrijft de store-tekst in één project, vertaalt beide daarna naar 50 talen, en exporteert in één keer een set die overeenkomt met de afmetingen van App Store Connect en Google Play Console — zodat hetzelfde werk twee listings voedt in plaats van twee aparte trajecten.

Mokbi publiceert ze ook. Het stuurt de listing en assets rechtstreeks naar Google Play via de Play Developer API, en zet de versie klaar in App Store Connect zodat jij die kunt indienen. Apple vereist zelf die laatste Indienen-stap en review, dus die laatste tik blijft bij jou (een regel van Apple, geen beperking van Mokbi). Zo stuur je hoe dan ook de listing-updates van beide consoles vanaf één plek aan, met één abonnement: de editor is gratis met watermerk, en Solo (€29,99/maand) of Studio (€49,99/maand) ontgrendelen onbeperkt exporteren en publiceren zolang je abonnee blijft.

Publiceer beide listings vanuit Mokbi →