Apple handelt 90% van de inzendingen binnen een dag af. De versnelde beoordeling lost de andere 10% niet op.

De mail komt altijd in dezelfde vorm binnen. Het is zes dagen geleden, de app staat nog steeds op Waiting for Review, de lancering stond voor morgen gepland, en of ik alsjeblieft iemand bij Apple wil bellen.

Dat kan ik niet. Dat kan niemand. Wat ik meestal wel kan, is uitzoeken wat die zes dagen betekenen, en na achttien jaar apps inzenden kan ik u vertellen dat het zelden aan de lengte van de wachtrij ligt.

Daar is een knop voor. Apple laat u een versnelde beoordeling aanvragen, het kost niets, en als de aanvraag wordt toegekend werkt hij binnen enkele uren. De meeste mensen die hem indrukken zitten in een situatie waarin hij niets kan uitrichten.

Het cijfer dat Apple publiceert, en het cijfer eronder

Apple zet het onomwonden op zijn App Review-pagina: "Gemiddeld wordt 90% van de inzendingen binnen 24 uur beoordeeld."

Dat cijfer klopt. De rest is waarschijnlijk waar u zit. In 2025 beoordeelde het App Review-team meer dan 9,1 miljoen inzendingen, ongeveer 25.000 per dag, waarmee het trage tiende deel uitkomt op zo'n 900.000 inzendingen per jaar die langer dan een dag duurden. U bent daar dus in ruim gezelschap, en wat telt is weten wat u daar heeft gebracht.

Het helpt ook te weten hoe weinig tijd een beoordeling kost. Een jaar eerder beschreef Apple zijn eigen bedrijf als bijna 500 toegewijde specialisten die meer dan 130.000 apps per week beoordelen. Jeff Johnson van Lap Cat Software maakte in mei de deling: ongeveer 260 inzendingen per beoordelaar per week, dus onder de tien minuten per stuk. In een verklaring in de Epic-zaak schatte een voormalig hoofd van App Review de beoordeling van een nieuwe app op zo'n dertien minuten.

Niemand besteedt dus zes dagen aan het bestuderen van uw app. Een beoordeling is enkele minuten aandacht. Die zes dagen zijn de tijd voordat iemand hem oppakt, of de tijd die uw inzending doorbracht op een traject dat trager is dan de hoofdrij, en allebei laten ze sporen na in uw eigen dashboard.

Waarom een inzending blijft liggen

Ruwweg in de volgorde waarin ik ze tegenkom.

• De eerste inzending vanaf een jong account is het traagste wat u Apple ooit stuurt. In 2025 wees Apple meer dan 138.000 ontwikkelaarsaanmeldingen af en sloot het 193.000 accounts wegens vermoedens van fraude, dus een account zonder geschiedenis heeft een ander risicoprofiel dan een account met veertig uitgebrachte versies. Updates van een gevestigde app gaan er in uren doorheen. Eerste inzendingen niet.
• Sommige categorieën roepen extra controles op: financiën, gezondheid, kinderen, dating, VPN's, crypto, gokken en alles met een medische claim eraan. De reviewpagina van Apple noemt de papieren die gevraagd kunnen worden, waaronder toelating van medische hardware, toestemming voor een handelsmerk en licenties. Een inzending die wacht op een document dat Apple niet heeft, staat niet in de rij maar geparkeerd.
• App Review heeft u misschien allang geschreven. Apple geeft aan dat ruim 40% van de onopgeloste kwesties onder richtlijn 2.1, App Completeness, valt, die crashes, tijdelijke inhoud en onvolledige informatie dekt. De alledaagse variant is een demo-account dat niet meer werkt, of een backend die u na het testen heeft uitgezet. Dat soort wachten stopt op het moment dat u antwoordt.
• De kalender doet hier veel werk. Apple plaatst elke december een bericht dat tijdgevoelige inzendingen vroeg moeten komen, omdat beoordelingen van 20 tot 26 december langer duren. September brengt het nieuwe OS en iedereen die in dezelfde weken zijn compatibiliteitsupdates uitbrengt. En 2026 is sowieso een zwaar jaar qua volume: de iOS-releases lagen in het eerste kwartaal 80% hoger dan een jaar eerder, met bijna 560.000 nieuwe apps in alleen de eerste helft.
• Een deel ervan is helemaal geen App Review. Contracten, belastinggegevens en bankgegevens staan buiten het beoordelingsproces en blokkeren de distributie op eigen kracht. Een betaalde app waarvan het Paid Apps-contract niet is getekend kan niet verkocht worden, wat een beoordelaar ook beslist, en in het dashboard ziet dat eruit als een beoordelingsvertraging.
• Een deel is zelf veroorzaakt. Een versie uit de beoordeling halen zet hem op Developer Rejected en de beoordeling begint weer van voren af aan, en iets aanpassen buiten de kleine set velden die tijdens de beoordeling open blijft, vereist precies dat. Mensen doen dat op dag vier en tellen het wachten daarna vanaf dag één.

Wat een versnelde beoordeling werkelijk is

Apple noemt twee situaties op zijn App Review-pagina. De ene is een kritieke bugfix, waarbij Apple vraagt om "de stappen op te nemen waarmee de bug in de huidige versie van uw app te reproduceren is". De andere is een app die aan een evenement hangt, waarbij de aanvraag "het evenement, de datum ervan en de band van uw app ermee" moet bevatten. De aanvraag gaat via een formulier op de ontwikkelaarssite, ingelogd, zodra de inzending al in de rij staat.

Het schuift uw inzending naar voren in de rij. De beoordeling zelf blijft dezelfde beoordeling met dezelfde maatstaf, alleen eerder. Een versnelde app wordt dinsdagochtend afgewezen om precies datgene waarvoor hij vrijdagmiddag zou zijn afgewezen.

Als hij wordt toegekend, gaat het snel. Het antwoord op de aanvraag komt meestal dezelfde of de volgende dag, en de beoordeling volgt binnen enkele uren daarna. Die snelheid is de hele aantrekkingskracht, en dat is de reden om zorgvuldig te zijn met waaraan u hem besteedt.

Lees de formulering van Apple over het evenement, die verraadt het spel. Apple raadt aan de release in App Store Connect te plannen en in te roosteren, en voegt er pas daarna aan toe dat u versnelling kunt aanvragen als de app nog in beoordeling is en het evenement nadert. Het eerste antwoord van Apple op een deadline is de releaseplanner. Het formulier komt op de tweede plaats.

Hoe u een aanvraag schrijft die wordt toegekend

Eén alinea, concreet, controleerbaar door iemand die uw product nooit heeft gezien. Voor een bug: wat er stuk is, sinds welke versie, voor welke gebruikers, de stappen om het te reproduceren, wat de fix verandert, en een getal dat de omvang laat zien. Een crashpercentage, het aantal supporttickets, de eensterrecensies van de afgelopen 48 uur. Voor een evenement: de datum, de band van uw app ermee, en waarom de datum niet kan schuiven.

De aanvragen die stranden zijn die waarvan de urgentie voor u echt is en voor Apple onzichtbaar. De campagne begint maandag. De klant kreeg vrijdag toegezegd. De investeerdersdemo is donderdag. We zijn al laat. Elk daarvan is een echt probleem en geen ervan is een bug of een evenement.

Vraag één keer, via één kanaal. Een formulieraanvraag plus een supportzaak plus een forumdraadje over dezelfde build vermenigvuldigen uw kansen niet, en degene die de aanvraag leest ziet alle drie.

De grenzen, die Apple niet op papier zet

• Er is geen gepubliceerd quotum. Apple spreekt van bijzondere omstandigheden, en elke aanvraag wordt op zichzelf beoordeeld. Reken op ongeveer één per jaar en u zit dicht bij hoe het mechanisme zich gedraagt.
• Aanvragen worden onthouden. Wie vaak vraagt, krijgt stilletjes geen toekenning meer, zonder waarschuwing en zonder melding, en u merkt het op de dag dat er echt iets stuk is en u de uwe aan een marketingdatum had uitgegeven.
• Het maakt van een afwijzing geen goedkeuring. Vindt de versnelde beoordeling een probleem met een richtlijn, dan is de aanvraag verbruikt en herstelt en herindient u net als iedereen. Bezwaar loopt via een apart spoor, de App Review Board, één bezwaar per niet-geslaagde inzending, en Apple vraagt eerst openstaande informatieverzoeken te beantwoorden.
• Het reikt niet tot iets buiten App Review. Een onbeantwoord 2.1-bericht, ongetekende contracten, onvolledige belasting- of bankgegevens, een lopende inschrijving, een build die crasht op het toestel van de beoordelaar. Een toegekende aanvraag verzet daar niets aan.
• Google Play heeft niets vergelijkbaars. Play zegt dat een beoordeling tot zeven dagen kan duren, in uitzonderlijke gevallen langer, en een persoonlijk ontwikkelaarsaccount dat na 13 november 2023 is aangemaakt moet daarnaast een gesloten test draaien met minstens 12 testers die 14 dagen aaneengesloten zijn aangemeld, voordat het productietoegang kan aanvragen. Geen formulier bekort dat, dus de enige manier om het goedkoop te betalen is vroeg beginnen.

Vier dingen die beter werken

Vroeg inzenden en de release vasthouden. Apple laat u een versie goedkeuren en hem daarna met de hand of op een gekozen datum uitbrengen. Play heeft beheerd publiceren, dat goedgekeurde wijzigingen vasthoudt tot u het zegt. Zodra goedkeuring en lancering twee losse gebeurtenissen zijn, verdwijnt de beoordelingstijd van het kritieke pad. De meeste versnellingsaanvragen die ik heb zien uitgaan waren de rekening voor het overslaan van die ene stap.

De fix zo bouwen dat er geen inzending voor nodig is. Feature flags en configuratie op afstand leggen de schakelaar in een binary die Apple al heeft beoordeeld en laten uw server bepalen hoe hij staat. Dat is gewone praktijk, en iets anders dan wat richtlijn 2.5.2 verbiedt, namelijk code downloaden die functies toevoegt of verandert. De adder is dat een noodstop in versie 1 mee moet, niet in de release waarop u nu wacht.

De App Review Information invullen alsof een vreemde ermee moet werken, want dat gebeurt ook, in minder dan tien minuten, op een toestel dat niet van u is. Een demo-account dat vandaag werkt, de backend aan gelaten, notities voor alles wat een beoordelaar niet zou raden, een korte video voor een flow die hardware vereist. Richtlijn 2.1 is ruim 40% van de onopgeloste kwesties en de goedkoopste vertraging op deze lijst om weg te nemen. Bent u al afgewezen, dan schreef ik apart over wat Apple onder 4.2 en 4.3 weigert, en er staat hier een pagina over een afgewezen app alsnog doorkrijgen.

Vaak genoeg uitbrengen zodat geen enkele release alles draagt. Liggen uw releases twee weken uit elkaar, dan is een beoordeling van twee dagen ruis. Brengt u twee keer per jaar uit, dan draagt elke inzending een kwart van de roadmap en is elke beoordeling een noodgeval. Het is hetzelfde ritme-argument als in mijn stuk over vroeg uitbrengen, en het geldt voor beoordelingstijd net zo direct als voor ranking.

Er is een vijfde die geen beoordeling verkort en het onderliggende probleem toch vaker oplost dan mensen verwachten. Tot 100 mensen uit uw eigen team kunnen een TestFlight-build binnen enkele minuten na de upload installeren, zonder enige beoordeling. Externe testers hebben voor de eerste build van een versie Beta App Review nodig, een aparte en kortere rij. Als u vanmiddag echte mensen nodig heeft die de fix draaien, loopt die weg niet langs de store.

Het ene geval waarin ik niet zou aarzelen

Dataverlies. Een crash bij het opstarten. Een gat in de beveiliging. Betalingen die geld aannemen en niets leveren. Alles waarbij elk uur gebruikers iets kost dat ze niet terugkrijgen. Daarvoor is het mechanisme gebouwd, de aanvraag schrijft zichzelf, en ik zou hem binnen het uur versturen.

Ik zou er ook van uitgaan dat hij afgewezen kan worden en al het andere parallel doen: een serverkant-verzachting als de app daar de leidingen voor heeft, een bericht op de plek waar uw gebruikers toch al klagen, en de fix in de gewone rij zodat hij hoe dan ook vooruit gaat.

Het wachten is een planningsprobleem

Een versnelde beoordeling is een gunst met een geheugen. Hij is ongeveer één goed noodgeval per jaar waard, en hij verandert wanneer uw app beoordeeld wordt, niet hoe.

De teams die nooit op Apple lijken te wachten zijn niet de teams met een contact binnen het bedrijf. Het zijn de teams die twee weken voor de datum die hun iets kon schelen hebben ingezonden, en die een kapotte functie vanaf hun eigen server kunnen uitzetten terwijl de fix de gewone rij doorloopt zoals die van iedereen.