Oprichters vragen hiernaar alsof er één vast getal bestaat. Dat is niet zo. Apple en Google beoordelen apps, maar beloven geen deadline. Beide publiceren een gebruikelijke termijn die vervolgens vaak als garantie wordt gezien. Ik breng vier consumentenapps uit in beide winkels — Luna, Smart Clip, Routina en Callendar — dus hieronder staat de planning waar ik in 2026 echt rekening mee houd, geen overgenomen afbeelding met een “gemiddelde beoordelingstijd”.
Realistische bandbreedtes, geen belofte
Dit zijn planningsgetallen. Een specifieke build kan sneller of langzamer worden beoordeeld. Gebruik ze als buffers, niet als SLA’s.
- Apple, gewone update van een bestaande app: vaak 24–48 uur. Veel updates zijn binnen een dag goedgekeurd. Daar ga ik van uit bij een bugfix of kleine functie voor een account dat Apple al kent.
- Apple, eerste inzending of ingrijpende wijziging: ik reserveer twee tot vijf dagen als planningsbuffer, en meer voor gevoelige functies. Apples hulp over de beoordelingsstatus noemt doelen van 50% binnen 24 uur en 90% binnen 48 uur. Dat zijn algemene doelen, geen deadline voor jouw app.
- Google Play, productie-update van een bestaande app: vaak enkele uren tot een paar dagen. Google spreekt zelf nog altijd van “enkele uren tot zeven dagen, en in uitzonderlijke gevallen langer”. Belangrijke Play-releases dien ik dagen van tevoren in, niet pas enkele uren.
- Google Play, eerste productie-release voor persoonlijke accounts die na 13 november 2023 zijn aangemaakt: de officiële testvereisten omvatten minimaal 12 testers die 14 opeenvolgende dagen deelnemen, gevolgd door een aanvraag voor productietoegang. Volgens Google duurt de beoordeling van die toegang meestal zeven dagen of korter, soms langer. Dit staat los van de beoordeling van de release.
Gecontroleerd op 8 oktober 2026: Apples algemene pagina over appbeoordeling noemt een andere algemene statistiek: 90% binnen 24 uur. De twee officiële pagina’s beschrijven verschillende doelen. Geen van beide garandeert een individuele lanceringsdatum; controleer de status in App Store Connect en houd marge aan.
Een release in twee winkels duurt zo lang als de langzaamste beoordeling
Moet het product op dezelfde ochtend in beide winkels verschijnen, dan krijg je niet de mediane Apple-tijd of de mediane Play-tijd. Je wacht op de winkel die het laatst klaar is, plus de afwijzing waarvoor je rekening had moeten houden.
De praktische planning die ik gebruik:
- Maak de build wanneer het product echt klaar is. Niet wanneer de landingspagina klaar is. De appwinkel beoordeelt je website niet.
- Dien eerst bij Apple in als de wijziging gevoelig ligt volgens de richtlijnen. Kinderapps, toetsenborden, achtergrondmodi en functies die “als een telefoongesprek rinkelen”. Apple zal dan vooral de productwerking beoordelen, niet alleen de vermelding.
- Dien bij Play op tijd in; vertrouw niet op geluk. Een gewone update gaat vaak snel. Een update met wijzigingen in beleidsverklaringen, doelgroep of nieuwe machtigingen blijft eerder liggen.
- Reken bij een eerste versie op één afwijzing. Na een afwijzing begint een volledige nieuwe beoordelingsronde; het is geen formaliteit die dezelfde dag wordt afgedaan. Heeft de lancering een externe deadline, reserveer dan marge voor twee rondes.
Waardoor de wachtrij echt langer wordt
Niet “de beoordelaar had een slechte dag”. Elk jaar spelen dezelfde vier factoren:
- De app is voor kinderen. Luna is een voorleesapp voor het slapengaan, ongeveer voor kinderen van twee tot negen jaar. De categorie voor kinderen, privacyvereisten die aansluiten op COPPA en gegenereerde teksten maken dit een inhoudelijke en veiligheidsbeoordeling, geen simpele controle van de build. Plan meer tijd in dan voor een weerapp-update.
- De app kan zien wat je typt. Smart Clip is een AI-toetsenbord en schrijfhulp in het deelvenster. “Volledige toegang” op iOS vraagt om vertrouwen. Privacyteksten, claims dat gegevens niet worden verkocht en een duidelijke demovideo zijn hier belangrijker dan een nieuw pictogram.
- De app zegt te helpen bij angst of aandacht. Routina is een checklist voor mensen met ADHD die het huis verlaten — slot, gas, sleutels, afgevinkt. Het is geen medisch hulpmiddel. De appvermelding moet dat duidelijk maken. Gezondheidsclaims kunnen van een update van 24 uur een week maken.
- De app doet nadrukkelijker iets wat het besturingssysteem al doet. Callendar geeft een vergaderalarm dat zich als een telefoongesprek gedraagt, ook in de stille modus en Focus. Alles wat Do Not Disturb lijkt te omzeilen, wordt handmatig beoordeeld.
De frameworkkeuze is bijna nooit de reden dat een beoordeling lang duurt. Native versus Flutter versus React Native verandert de build, niet de beoordelaar.
Zo zag dat eruit bij de vier apps
Ik verzin geen beoordelingstijden per build. Dit is geen ranglijst, en van één uitzonderlijk snelle build leer je de verkeerde les. Dit is het patroon bij het uitbrengen van deze vier apps:
- Luna — lunastorytelling.kids. De eerste vermelding in de categorie voor kinderen duurde het langst. Updates van de verhalenengine en lokalisatie verliepen daarna als gewone updates, zolang leeftijdsclassificatie, privacylabel en informatie over gegenereerde content overeenkomen met wat Apple al heeft goedgekeurd.
- Smart Clip — smart-clip-app.com. Een toetsenbord met schrijfhulp in 30 talen. De beoordeling draait om machtigingen en privacy, meestal niet om de codewijziging.
- Routina — routina-app.com. Checklist, haptische feedback en foto’s op het apparaat. Updates met alleen tekst- en tikwijzigingen gaan door als bij een gewone hulpprogramma-app. Tekst die op een behandeling lijkt, niet.
- Callendar — callendarmeetings.com. Agenda-alarmen die rinkelen. In de beoordelingsnotities bij de eerste versie moesten we laten zien hoe het alarm op een apparaat werkt. Daarna verliepen kleine fixes voor agendasynchronisatie zonder bijzonderheden.
Bij dezelfde vier apps was Play sneller met gewone productie-updates en langzamer toen een vermelding of vragenlijst verouderd was. De build was in orde; het formulier niet.
Zo plan je een datum die haalbaar is
- Kondig geen releasedatum aan voordat de eerste build ter beoordeling is ingediend. De landingspagina kan online; een persaankondiging nog niet.
- Houd een tweede, kleinere build gereed. Als Apple een formulering afwijst, wil je die dezelfde middag opnieuw kunnen indienen, niet pas na een nieuwe sprint.
- Schrijf de beoordelingsnotities als een demoscript. “Tik hier en dan hier; je ziet X.” Beoordelaars zijn niet je gebruikers.
- Stem de privacylabels af op de build. Met een toetsenbordupdate en het privacylabel van vorig jaar verlies je zo een week.
- Is het Play-account nieuw, begin dan met de gesloten test met 12 testers zodra je een crashvrije build hebt. Die klok van 14 dagen houdt geen rekening met een website die al klaar is.
De vraag die je een leverancier moet stellen
Niet: “Weet je hoe lang de beoordeling duurt?” Iedereen zal 24 uur zeggen.
Vraag: “Wanneer dienen jullie de app in ten opzichte van de datum die we aan het bestuur hebben genoemd, en wat gebeurt er als Apple de app één keer afwijst?” Het antwoord laat zien of ze in 2026 een app hebben uitgebracht of een blogpost uit 2022 napraten.
Wil je voor je app een opleversprint met afgesproken scope, dan spreken we de scope, planning en prijs af voordat we beginnen. De afgesproken scope kan de voorbereiding voor beide appwinkels omvatten. De externe beoordeling valt buiten die planning; Apple en Google bepalen hoelang die duurt.