Wat je kunt wijzigen zonder nieuwe app-versie: Apple vs Google
Voordat je een store listing aanraakt, is er één vraag die het waard is om te beantwoorden: kost deze wijziging me een volledige indiening, of kan die stilletjes de deur uit? Krijg je het antwoord verkeerd, dan zit je óf in een reviewwachtrij waar je geen rekening mee hield, óf denk je dat een wijziging live is terwijl die nog wacht op goedkeuring. De twee stores beantwoorden die vraag op tegenovergestelde manieren, en dat verschil is precies de reden waarom listings synchroon houden tussen beide zo vervelend is.
Hier is de eerlijke, veld-voor-veld versie — te beginnen met de matrix, gevolgd door de redenering achter de regels van elke store, zodat je de gevallen kunt voorspellen die deze tabel niet expliciet benoemt.
De matrix
Elk veelvoorkomend listing-veld, en wat elke store eist als je het wijzigt. "Nieuwe versie / release" betekent dat de store de wijziging behandelt als onderdeel van een indiening die je moet versturen; "beoordeeld" betekent dat er een menselijke of geautomatiseerde controle plaatsvindt voordat het live gaat.
| App-icoon | Het primaire icoon zit in de binary — wijzigen vereist een nieuwe build. Beoordeeld samen met die build. | Store-icoon is een listing-asset. Geen nieuwe release nodig. Beoordeeld. |
Twee dingen vallen op. Apple sluist bijna alles door een versie-record. Google laat de hele listing zelfstandig bewegen. Geen van beide stores slaat review over bij de assets die ertoe doen — het woord "beoordeeld" duikt in bijna elke cel op. De echte vraag is dus zelden "wordt dit beoordeeld", maar "trekt deze wijziging een indiening met zich mee".
Apple: een nieuw versie-record is niet hetzelfde als een nieuwe build
Dit is het onderscheid waar mensen over struikelen. Op de App Store creëert het wijzigen van je screenshots, naam, ondertitel, keyword-veld of beschrijving een nieuwe versie van je listing. Dat klinkt alsof je terug moet naar Xcode. Dat hoeft niet. Apple neemt je huidige metadata automatisch over in de nieuwe versie, en een wijziging die alleen metadata betreft vereist geen nieuwe app-code — je koppelt een build (App Store Connect vereist er nog steeds één bij de versie) en verandert niets aan wat de app doet. Je bewerkt de in de wachtrij staande velden, dient in, en één reviewronde dekt ze allemaal.
"Geen nieuwe code, maar nog steeds beoordeeld" is dus de juiste manier om het te onthouden. Geen compileerstap en geen nieuwe functies — maar de wijziging gaat wel App Review in en wacht haar beurt af voordat ze openbaar wordt. Bundel je wijzigingen: omdat één versie-record nieuwe screenshots, een herschreven beschrijving, een nieuwe ondertitel en bijgewerkte keywords tegelijk kan bevatten, is er geen reden om aan elk daarvan apart een reviewronde te besteden.
Het app-icoon is de uitzondering die wél een build vereist. Je primaire icoon zit ingebakken in de binary en wordt daaruit getekend, dus een echt nieuw icoon betekent een nieuwe build. Hetzelfde geldt voor alternatieve iconen — die moeten in de app gebundeld zijn om bruikbaar te zijn, dus het toevoegen van één is een build, geen listing-wijziging.
De twee ontsnappingsroutes van Apple
Promotietekst. Dit is het enige veld dat je kunt wijzigen zonder versie en zonder review. Het is 170 tekens, staat boven de beschrijving, en je werkt het bij wanneer je maar wilt — handig voor een actie, een lanceringsbericht of tijdgevoelige tekst. Het beïnvloedt de zoekranking niet en maakt geen deel uit van een indiening, en precies daarom is het het snelste dat je op de store kunt wijzigen. Als iets vandaag nog live moet, is dit het veld dat dat kan.
Product Page Optimization. Met PPO kun je tot drie varianten van je screenshots, app previews en icoon testen tegen je live productpagina — zonder een nieuwe app-versie uit te brengen. Dit komt het dichtst in de buurt van wat Apple biedt om beeldmateriaal buiten een normale indiening om te wijzigen. Twee kanttekeningen houden het eerlijk: de metadata van de variant moet nog steeds goedgekeurd worden voordat de test start (dus het wordt beoordeeld, niet direct doorgevoerd), en elk icoon dat je wilt testen moet al deel uitmaken van de huidige app-binary. PPO verandert wat bezoekers zien; het slaat geen review over.
Google Play: publiceer de listing zonder release
Play werkt precies andersom. Je store listing — titel, korte beschrijving, volledige beschrijving, screenshots, feature graphic, icoon, promovideo — is zelfstandig te bewerken en te publiceren, zonder gekoppelde nieuwe app-release. Je maakt de wijzigingen, en ze verschijnen in het Publishing-overzicht onder wijzigingen die klaarstaan om ter review te versturen. Je verstuurt ze, ze doorlopen de review van Google, en ze gaan live los van elke build.
Een paar dingen om precies te houden zodat je het niet overdrijft. De wijzigingen worden nog steeds beoordeeld — Play's review geldt ook voor listing-wijzigingen, en elementen zoals de app-naam en het icoon worden gecontroleerd, dus het is geen stille, directe wissel. En de listing kan niet losstaan van een uitgebrachte app: Play vereist dat de app al een eerdere release heeft voordat er een openbare listing is om te bewerken. Je kunt geen op zichzelf staande store-pagina publiceren voor iets dat nog nooit is uitgebracht. Managed publishing voegt nog een complicatie toe die het weten waard is — als het aanstaat, wachten goedgekeurde wijzigingen tot je ze actief publiceert, wat een functie is, geen vertraging, zodra je het verwacht.
De asymmetrie, en waarom die je tijd kost
Zet de twee modellen naast elkaar en de scheiding is helder. Apple koppelt vrijwel elke tekst- en beeldwijziging aan een versie-record en een reviewronde, met promotietekst en PPO als enige uitwegen. Google ontkoppelt de listing volledig van de release, beoordeelt de wijzigingen, en levert ze uit op eigen schema, zolang de app al bestaat.
Die asymmetrie is stilletjes duur wanneer je beide stores runt. Dezelfde screenshot-vernieuwing is op de ene store een indiening met versie-record en op de andere een op zichzelf staande listing-update. Een herschreven beschrijving is bij Apple een beoordeelde versie en bij Google een beoordeelde listing-wijziging. De inhoud is hetzelfde; de mechaniek niet, dus een wijziging die op Play één actie is, wordt op de App Store een andere actie — en je vergeet makkelijk de ene uit te leveren terwijl je de andere doet, of denkt dat iets bij Apple live staat terwijl het nog in review zit.
Waar Mokbi in past
Deze asymmetrie tussen stores is precies de reden waarom een publishing-tool zichzelf terugverdient. Mokbi begon als een screenshot-editor, maar een listing is tekst en beeld samen — dus ontwerpt het de screenshotset en schrijft het de listing-tekst voor beide stores op één plek: App Store naam, ondertitel, keyword-veld en beschrijving; Play titel, korte beschrijving en volledige beschrijving. Je krijgt de velden die elke store daadwerkelijk indexeert, toegesneden op die store, in plaats van één blok tekst dat je twee keer plakt.
Daarna vertaalt het de hele listing — screenshots en tekst — naar 50 talen, zodat een wijziging die je één keer maakt in elke markt in het juiste veld terechtkomt, in plaats van Engels te blijven in een listing die overal elders wél lokaal is. En het publiceert: Mokbi zet de afgeronde listing direct naar Google Play via de Play Developer API, en zet hem klaar in App Store Connect om in te dienen — Apple vereist aan die kant nog steeds de laatste Submit en reviewronde, wat een Apple-regel is en precies de asymmetrie tussen de stores waar dit hele artikel over gaat. Die laatste review is ook waar de klok uit dit artikel begint te tikken.