Waarom duurt de app-beoordeling zo lang?

Een trage beoordeling betekent niet automatisch dat je app een probleem heeft. Leer hoe je een wachtrijvertraging onderscheidt van een geblokkeerde inzending, wat Apple en Google daadwerkelijk beloven, en wanneer je contact opneemt met de ondersteuning.

Je hebt de build geüpload, de schermafbeeldingen gecontroleerd en je lancering gepland. En dan gebeurt er niets. App Store Connect zegt nog steeds 'Wachten op beoordeling', of Play Console houdt je wijzigingen in behandeling. Ondertussen maakt elke dag van onzekerheid het moeilijker om marketing, klantenondersteuning en een release-aankondiging te coördineren.

Het frustrerende is dat een vertraging meerdere mogelijke verklaringen heeft. Je inzending wacht misschien gewoon op zijn beurt. Een reviewer heeft misschien informatie nodig. Je build is misschien helemaal niet bij de beoordeling aangekomen. Of de beoordeling is misschien al klaar, maar de publicatie wacht op jou. Deze gids legt uit hoe je die situaties uit elkaar houdt. Hij richt zich op Apple App Review, met een aparte vergelijking met Google Play. Bronnen zijn gecontroleerd op 3 oktober 2026.

Hoe lang zou een app-beoordeling moeten duren?

Apple zegt dat gemiddeld 90% van de inzendingen binnen 24 uur wordt beoordeeld. Dat is nuttige context, maar het is geen gegarandeerde doorlooptijd voor jouw individuele app. Sommige inzendingen vallen buiten dat venster, en de statistiek geeft je geen voltooiingstijd voor die uitzonderingen. Apple waarschuwt ook dat onvolledige inzendingen de beoordeling kunnen vertragen. [1]

Behandel dat getal als een planningsreferentie, niet als een lanceringsverplichting. Een inzending die langer dan een dag duurt, is op zichzelf geen bewijs van afwijzing of een kapot account. Evenmin mag een gemiddelde je overhalen om een bruikbaar bericht te negeren. De status en de correspondentie met de reviewer wegen zwaarder dan vergelijkingen met de snelste goedkeuring van een andere ontwikkelaar.

Identificeer eerst waar de vertraging werkelijk zit

Lees de precieze status in plaats van elke gele indicator te vertalen naar 'Apple beoordeelt mijn app'. 'Waiting for Review' betekent dat de inzending in de wachtrij staat; 'In Review' betekent dat de beoordeling is begonnen. 'Pending Developer Release' betekent dat de app is geaccepteerd maar nog je vrijgaveactie nodig heeft. 'Waiting for Export Compliance' is een ander proces. Een geaccepteerd item kan ook ongepubliceerd blijven als een ander item in de inzending is afgewezen. [2]

Controleer de app-versie en inzending samen, niet alleen de geüploade build. Een schermafbeelding van de buildlijst kan een ander verhaal vertellen dan de inzendingspagina. Noteer de versie, het buildnummer, het tijdstip van inzending en de huidige status. Dat kleine verslag voorkomt dat je een oudere build oplost of een TestFlight-inzending verwart met een App Store-release.

Reviewers moeten de volledige app ervaren

Een beoordelaar kan een functie niet beoordelen die hij niet kan bereiken. Apple's indieningschecklist vraagt om volledige toegang, een actief demo-account of geschikte demomodus, benodigde hardware of voorbeeldbronnen, en live backend-services. Het vraagt ontwikkelaars ook om niet-vanzelfsprekende functies en aankopen uit te leggen in de beoordelingsnotities. Deze vereisten maken toegang een verstandige eerste plek om te onderzoeken. [3]

Test de exacte inloggegevens die je hebt verstrekt, bij voorkeur op een schoon apparaat. Controleer of een account e-mailverificatie, een betaalde machtiging, een uitnodiging of een eenmalig wachtwoord nodig heeft. Probeer het onboardingpad zonder je ontwikkelaccount. Als een functie een bepaalde regio of een tweede gebruiker vereist, leg dan uit hoe de reviewer die opstelling kan reproduceren. Ga er niet van uit dat ze je beoogde workflow zullen afleiden.

Een korte, reproduceerbare walkthrough is nuttiger dan een verkooppraatje. Bijvoorbeeld: meld je aan met het meegeleverde account, open Bibliotheek, selecteer het voorbeeldproject en tik op Exporteren. Vermeld elke verwachte beperking en leg uit waarom die bestaat. Dit koopt geen prioriteit; het vermindert vermijdbare dubbelzinnigheid wanneer iemand je inzending bereikt.

Een afwijzing heeft een antwoord nodig, niet meer wachten

Wanneer Apple een app afwijst, legt het bericht het probleem en de relevante richtlijn uit. Via App Store Connect kun je antwoorden en ondersteunend materiaal bijvoegen. Apple stelt ook dat een afwijzing van metadata kan worden opgelost en opnieuw ingediend met dezelfde build. Een nieuwe binary is dus niet altijd nodig. [4]

Reageer op het specifieke bezwaar. Als de reviewer een functie niet kon vinden, geef dan de navigatiestappen. Als hun zorg een misleidende schermafbeelding is, corrigeer dan de schermafbeelding. Als je het oneens bent, leg dan het gedrag uit en lever bewijs in plaats van te herhalen dat concurrerende apps het ook doen. Scheid wat je hebt gewijzigd van wat je Apple vraagt te verduidelijken.

Houd een eenvoudig issuelogboek bij: de vraag van de reviewer, jouw antwoord, het gewijzigde asset of build en de volgende vereiste actie. Dat maakt latere correspondentie gemakkelijker te volgen. Het voorkomt ook dat een team onafhankelijk verschillende uitleg indient. Reviewcommunicatie is een debuggesprek, geen wedstrijd om het langste antwoord te sturen.

Build-verwerking en TestFlight zijn afzonderlijke controlepunten

Een geüploade build is niet noodzakelijkerwijs klaar voor indiening. Apple's build-statusreferentie onderscheidt verwerking, ontbrekende compliance-informatie en gereedheid om in te dienen. Het onderscheidt ook TestFlight's Wachten op beoordeling en In bèta-beoordeling staten van beschikbaarheid voor interne testers. Externe bètatests kunnen TestFlight App-beoordeling vereisen. [5]

Als je bèta vastzit, controleer dan de buildstatus voordat je een probleem met de beoordelingswachtrij van de App Store zoekt. Bij 'Missing Compliance' instrueert Apple ontwikkelaars om de encryptievragen te beantwoorden of de relevante documentatie te leveren. Sommige builds kunnen via hun configuratie een toepasselijke vrijstelling aangeven, maar je moet nauwkeurig antwoorden in plaats van instellingen te wijzigen alleen om de prompt te omzeilen. [6]

Goedgekeurd betekent niet altijd onmiddellijk beschikbaar

Apple's publicatieworkflow scheidt het kiezen van een build, het instellen van beschikbaarheid, indienen, het oplossen van beoordelingsproblemen en distributie. Het zegt dat een goedgekeurde app tot 24 uur kan duren om live te gaan. Je kiest ook of de release handmatig, automatisch of gefaseerd is. Controleer die instellingen voordat je een goedgekeurde versie beschrijft als "nog in beoordeling". [7]

Voor updates verspreidt een gefaseerde release de versie geleidelijk over zeven dagen naar in aanmerking komende gebruikers met automatische updates. Dat is een uitrolkeuze, geen zeven extra dagen beoordeling. Als één klant nog een oudere versie ziet, bevestig dan eerst de releasemethode en beschikbaarheid in plaats van aan te nemen dat de beoordelaar goedkeuring heeft onthouden. [8]

Google Play heeft een ander beoordelingsvenster

Pas de timing van Apple niet toe op Google Play. Google zegt dat beoordelingen een paar uur tot zeven dagen kunnen duren, en langer in uitzonderlijke gevallen. Het publicatieoverzicht waarschuwt ook dat het indienen van een andere wijziging terwijl wijzigingen in behandeling zijn, de app terug kan zetten in de beoordelingswachtrij. Herhaalde kleine bewerkingen kunnen dus een voorspelbare release tegenwerken. [9]

Het publicatieoverzicht van Play Console onderscheidt wijzigingen die in beoordeling zijn van wijzigingen die klaar zijn om te publiceren. Met beheerde publicatie ingeschakeld zijn goedkeuring en publicatie afzonderlijke beslissingen. Kijk naar de wachtrij met wijzigingen, niet alleen of de nieuwe vermelding zichtbaar is op een telefoon. Voltooi het beoogde releasepakket voordat je het indient en vermijd niet-gerelateerde bewerkingen tijdens het wachten, tenzij iets echt correctie behoeft.

Een praktisch voorbeeld: diagnose stellen vóór opnieuw indienen

Stel je een gewoonte-tracking-app voor die op maandagochtend is ingediend. Op dinsdagavond begint de oprichter hem opnieuw te bouwen omdat de goedkeuring niet is gekomen. Voordat ze dat doen, controleren ze drie dingen: of de versie daadwerkelijk in de wachtrij staat, of de beoordeling een bericht heeft gestuurd en of het geleverde account de onboarding kan voltooien. Dit is een illustratief scenario, geen gemeten AsoTheory-klantcase.

Als de app gewoon wacht en de toegang werkt, biedt een vervangende build geen aangetoonde oplossing. Als een reviewer een inlogfout meldt, lost het repareren van de toegang een echt obstakel op. Als de status 'Pending Developer Release' is, is de juiste actie vrijgeven, niet opnieuw indienen. Dezelfde verstreken tijd kan drie totaal verschillende reacties vereisen. Daarom komt het diagnosticeren van de status vóór het kiezen van een remedie.

Wanneer moet je contact opnemen met Apple?

Gebruik voor een onverklaarde, ongewoon lange vertraging de contactroute voor beoordeling van Apple met een beknopte tijdlijn en inzendingsidentificaties. Beschrijf de huidige staat, eventuele eerdere correspondentie en wat je al hebt gecontroleerd. Er is geen universele drempel in dagen in de aangehaalde richtlijnen die escalatie garandeert. Verzin er geen en beloof niet dat een ondersteuningsbericht je app vooruit zal helpen.

Versnelde beoordeling is een apart verzoek. Apple geeft voorbeelden zoals een kritieke bugfix of een release die is gekoppeld aan een evenement waar je direct bij betrokken bent. Leg de werkelijke omstandigheid en impact uit; gewoon marketingongeduld is niet hetzelfde. Een versneld verzoek moet niet worden gepresenteerd als een gegarandeerde snelkoppeling. [1]

Plan de lancering rond onzekerheid

Een nuttige interne release-opmerking heeft vier velden: wat er verandert, wat klanten momenteel kunnen openen, wie de beoordelingscorrespondentie in de gaten houdt, en wat de aankondiging triggert. Wijs één persoon aan als eigenaar van de inzending. Spreek een incheckschema af in plaats van dat iedereen de hele middag de console ververst. Houd het bewijsmateriaal bij elkaar, inclusief beoordelaarsberichten en de exacte ingediende versie. Niets hiervan verkort Apple's wachtrij, maar het voorkomt dat onzekerheid leidt tot onnodige herbouwsels of tegenstrijdige beslissingen.

Als je release een nieuw abonnement toevoegt of de onboarding verandert, bereid dan ondersteuningsantwoorden voor voordat de goedkeuring binnenkomt. Zorg ervoor dat je marketinglinks de versie beschrijven die mensen daadwerkelijk kunnen downloaden. Kondig niet aan dat een functie live is alleen omdat de build is geaccepteerd. Zorg voor een eerste lancering voor een fallback-bericht op de landingspagina. Dit zijn operationele aanbevelingen, geen store-vereisten of beloften over beoordelingssnelheid: hun waarde is dat je team nog steeds verstandig kan handelen wanneer de tijdlijn buiten zijn controle ligt.

Zet reviewvoorbereiding op een releasechecklist: werkende toegang, duidelijke notities, geteste aankoopstromen, nauwkeurige assets, gemonitorde correspondentie en een bewuste publicatie-instelling. Laat ruimte tussen indiening en een vaste campagnedatum. Als timing essentieel is, beslis dan van tevoren wat er gebeurt als goedkeuring laat komt: pauzeer de aankondiging, houd de huidige versie beschikbaar of communiceer een herzien venster.

Maak ten slotte onderscheid tussen bewijs en verhalen. Lange wachttijden van andere ontwikkelaars kunnen echt zijn, maar ze bewijzen niet waarom jouw app vertraging oploopt. Noch de aangehaalde Apple- noch Google-richtlijnen stellen een universele verklaring vast, zoals door AI gegenereerde apps die een achterstand veroorzaken. De nuttige vraag is niet "welk gerucht verklaart dit?" maar "in welke staat is mijn inzending en is er een actie die ik daadwerkelijk kan ondernemen?"

Gerelateerd

Blog · Casestudy's · Free ASO tools · Producten · Privacy en voorwaarden · AsoTheory