App Review in 48 uur: wat klopt, wat overdreven is en wat niet waar is

Onder iOS-ontwikkelaars lopen de gemoederen momenteel hoog op, zowel op X als in WhatsApp-community's, waaronder een die ik beheer. Het gaat er over reviews die maar blijven duren en beëindigde accounts, en er worden recepten uitgewisseld om « binnen 48 uur goedgekeurd te worden »: uitgebreide review notes, een demovideo, een telefoontje met Apple om in een aparte wachtrij te komen, een minimalistische MVP om « de stapel van 14 dagen » te vermijden…

In die adviezen zitten heel goede inzichten. Maar ook onbewezen beweringen en een of twee ideeën die, verkeerd toegepast, veel meer kunnen kosten dan een afwijzing.

De wachttijden en de beëindigingen verdienen elk een eigen hoofdstuk, omdat ze de rest in perspectief plaatsen.

Voor de context (al « weet » u, nu u op deze site bent beland, waarschijnlijk wie ik ben): ik publiceer sinds 2008 in de App Store, zowel mijn eigen apps als apps voor klanten. Ik heb elk advies naast wat Apple zwart op wit schrijft op zijn App Review-pagina, in de App Review Guidelines en in de App Review-help gelegd. Dit houdt stand, en dit niet.

---

Eerst die 48 uur in perspectief plaatsen

De recepten die rondgaan wekken de indruk dat 48 uur een prestatie is. Op papier is dat de norm die Apple zelf noemt: het App Review-team werkt 24 uur per dag, over de hele wereld (Cupertino, Cork en elders), en streeft ernaar minstens 50% van de inzendingen binnen 24 uur en 90% binnen 48 uur te behandelen.

In de praktijk ligt het genuanceerder. Die cijfers zijn gemiddelden over alle inzendingen, en een groot deel bestaat uit updates van al gepubliceerde apps, die vaak binnen enkele uren worden goedgekeurd. De afgelopen weken werden sommige van mijn updates na 7 uur goedgekeurd, andere na 12 uur. Een nieuwe app kan daarentegen veel langer wachten: op het moment dat ik dit schrijf, zijn sommige van mijn nieuwe apps al meer dan tien dagen in review. Dat is lang, maar zo gaat het nu eenmaal.

Apple heeft onlangs ook cijfers gedeeld. Op een vraag van MobileGamer.biz op 20 oktober gaf het bedrijf aan in de voorafgaande twaalf weken gemiddeld 378.000 inzendingen per week te hebben behandeld, met een gemiddelde doorlooptijd van 1,5 dag voor alle apps samen en 14 uur voor kleine updates. Het verduidelijkte ook dat sommige nieuwe apps langer duren als ze een grondig onderzoek vereisen. Voor zo'n volume is het gemiddelde opmerkelijk; de afwijkingen zitten vooral bij eerste inzendingen.

Om die wachttijden te volgen had de community vroeger een eigen hulpmiddel. De oudere garde herinnert zich appreviewtimes.com, begin jaren 2010 gelanceerd door mijn vriend Dave Verwer, de auteur van iOS Dev Weekly. Het principe was eenvoudig: ontwikkelaars twitterden hoe lang hun reviews duurden met de hashtag #iosreviewtime (ja, het heette toen nog Twitter), en de site berekende een gemiddelde. In de tijd dat je in weken moest rekenen, was het een onmisbaar hulpmiddel om verwachtingen van klanten te beheren.

In 2019 sloot Dave de site om de best mogelijke reden: reviews waren zo snel geworden, ongeveer een dag, dat meten weinig zin meer had. Hij heeft de site nooit heropend. Dave is deze zomer overigens met de Swift Package Index bij Apple gaan werken; Alex Ozun heeft iOS Dev Weekly overgenomen.

Het resultaat: in 2026 bestaat er geen toonaangevende communitybarometer meer, alleen losse ervaringen op forums en sociale media. Een teken des tijds: het hulpmiddel dat sloot omdat reviews snel waren geworden, zou vandaag weer van pas komen.

Een korte geschiedenis van de tijd

Het is niet de eerste keer dat de doorlooptijden veranderen. In de begindagen van de App Store kon een review meerdere weken duren. Mijn allereerste app wachtte 26 dagen op goedkeuring en verscheen op 14 juli 2008, vier dagen na de opening van de App Store. Daarna zakte de termijn naar een week, lange tijd de norm. Vervolgens versnelde Apple het proces sterk, tot één tot drie dagen gebruikelijk werd. Sinds begin 2026 lopen de wachttijden voor nieuwe apps weer op, en de reden verdient een eigen hoofdstuk (hieronder).

Mikken op 48 uur betekent dus niet dat u een voorkeursbehandeling zoekt: u wilt binnen het normale proces blijven, in de wetenschap dat dit proces voor een lancering tegenwoordig in dagen wordt geteld. Plan daarop.

De echte vraag wordt dan: waardoor raakt een inzending uit dat proces? Apple geeft een waardevolle aanwijzing op zijn App Review-pagina: meer dan 40% van de onopgeloste problemen valt onder guideline 2.1, App Completeness — crashes, voorlopige inhoud, ontbrekende informatie. Niet de subjectiviteit van de reviewer vertraagt de meeste apps, maar een onvolledige inzending.

---

Codeagents: meer apps, langer wachten

Waarom lopen de wachttijden weer op? De waarschijnlijkste verklaring past in één woord: agents.

Claude Code, Codex, Cursor, de agents in Xcode: een iOS-app schrijven was nog nooit zo toegankelijk. Volgens Sensor Tower, geciteerd door The Information, ontving de App Store 235.800 nieuwe apps in het eerste kwartaal van 2026, 84% meer dan een jaar eerder — de sterkste gemeten groei in vier jaar. Over het hele eerste halfjaar schat Sensor Tower het aantal nieuwe apps op ongeveer 560.000, het dubbele van het jaar ervoor, terwijl het aantal downloads slechts met 2% steeg. Apple schreef zelf in zijn fraudebestrijdingsrapport van mei dat AI-ontwikkeltools het aantal inzendingen doen stijgen.

Apple houdt vast aan zijn doel van 90% binnen 48 uur en heeft zijn organisatie aangepast: meer automatisering en voorrang voor updates. Wat ontwikkelaars zien, past bij die keuze: updates van gevestigde apps komen nog steeds snel door de review, nieuwe apps wachten langer.

De goede kant: what a great time to be a developer

Dat is in de eerste plaats om allerlei redenen uitstekend nieuws. De drempel om te programmeren was nog nooit zo laag. Designers, vakexperts en onafhankelijke makers die nooit Swift zouden hebben geleerd, kunnen nu een nuttige app uitbrengen. Ervaren ontwikkelaars leveren in een week wat vroeger een kwartaal kostte. Ik werk zelf dagelijks met agents: ze schrijven SwiftUI, tests en zelfs een eerste versie van review notes.

Maar let op: zeggen dat de drempel verdwenen is, zou een leugen zijn. Een agent schrijft code; hij weet niet voor u welk framework u moet kiezen, welk pattern standhoudt als de app groeit, hoe Swift-concurrency, StoreKit of permissies zich gedragen, of waarom een review vastloopt. Agents versterken wat u al weet. Hoe beter u het platform kent, hoe sneller ze u maken; hoe minder u ervan weet, hoe sneller u problemen opstapelt die u niet kunt duiden.

De ingrediënten zijn voor iedereen hetzelfde: Swift, SwiftUI, Xcode, de Human Interface Guidelines en nu een agent. Wat een geweldige app maakt, is hoe u ze doelbewust en zorgvuldig samenbrengt: een bestaansreden die in één zin te formuleren is, één bron van waarheid voor de data, eerlijk getoetste toegankelijkheid en tests op echte apparaten. Een agent kan het scherm schrijven; hij vertelt u niet of de app bestaansrecht heeft. Of erger nog: hij verandert in een trotse moeder: “Wat een fantastisch idee, schat!” — en helpt u vervolgens een miljard tokens te verbranden voor een app waarvan de volledige doelgroep bestaat uit uzelf, uw moeder, uw kat, uw kanarie en misschien — heel misschien — uw partner. Ik heb deze hele aanpak, van Apples acht ontwerpprincipes tot de publicatie, uitgewerkt in Het recept voor een geweldige iOS-app.

Goed gebruikt helpen ze ook om aan de regels te voldoen. Een agent kan uw purpose strings nalezen, controleren of het verwijderen van een account bestaat, uw gebruikerspad toetsen aan de guidelines en niet voor de hand liggende functies opsommen die gedocumenteerd moeten worden. Alles wat dit artikel beschrijft, kan een agent vóór u controleren.

Om het u makkelijker te maken, bied ik u trouwens een skill aan die helpt fouten op te sporen voordat u indient: app-review-skill. Het is geen garantie op goedkeuring, maar wel een vangrail. 😉

Kortom: what a great time to be a developer.

De luchtspiegeling van miljonair worden met drie prompts

De keerzijde is het verhaal dat deze golf vergezelt. Overal duikt dezelfde belofte op: drie prompts, een abonnement (of overal advertenties), en binnen drie dagen bent u miljonair.

Spoiler: dat klopt niet. En de cijfers spreken boekdelen. Het rapport State of Subscription Apps 2026 van RevenueCat, gebaseerd op meer dan 115.000 apps en 16 miljard dollar aan omzet, laat zien dat:

• de mediane app één jaar na de lancering ongeveer $ 72 per maand oplevert;
• slechts 17,3% van de apps in de eerste twee jaar $ 1.000 maandelijkse omzet haalt, en 4,6% de $ 10.000 passeert;
• zelfs de best presterende 10% na een jaar net boven $ 2.574 per maand uitkomt: ver, heel ver van een miljoen;
• apps die in 2025 of later zijn gelanceerd slechts 3% van de abonnementsomzet vertegenwoordigen, terwijl apps van vóór 2020 69% binnenhalen.

En dan hebben we het over apps die serieus genoeg zijn om een abonnementssysteem te hebben geïntegreerd.

Iedereen denkt de next big idea te hebben. Sorry dat ik u weer met beide benen op de grond zet. Als uw idee nog niet in de App Store bestaat, zijn er maar twee mogelijkheden: het is al geprobeerd en werkte niet, of een honderdtal andere mensen bouwt het op dit moment. En met agents worden die honderd er al snel duizend.

Dat is geen pessimisme, maar een goed gedocumenteerd verschijnsel: gelijktijdige ontdekkingen. Alexander Graham Bell en Elisha Gray dienden in 1876 op dezelfde dag een octrooiaanvraag voor de telefoon in. Darwin en Wallace kwamen onafhankelijk van elkaar tot natuurlijke selectie en presenteerden hun werk in 1858 zelfs samen. Newton en Leibniz vonden parallel de infinitesimaalrekening uit. Geen magie: op een bepaald moment beschikt iedereen over dezelfde hulpmiddelen, dezelfde problemen en dezelfde toegang tot informatie. Twee geesten met hetzelfde probleem en dezelfde hulpmiddelen komen vanzelf tot dezelfde oplossing. Zoals de vaak aan Victor Hugo toegeschreven uitspraak luidt: niets is krachtiger dan een idee waarvan de tijd gekomen is.

Het advies dat daaruit volgt: houd uw idee niet geheim uit angst dat iemand het steelt. Anderen werken er al aan. De mensen met wie u erover praat, kunnen u zelfs wijzen op concurrerende apps die u tot nu toe waren ontgaan. Het verschil zit niet in het idee, maar in de uitvoering, de distributie, de tijd en uw persoonlijke inbreng.

Ik ken ontwikkelaars van wie de apps tussen $ 80.000 en meer dan een miljoen dollar per maand opleveren. Ze bestaan, ze zijn briljant en hebben vaak jaren van iteraties achter de rug. Ze zijn duidelijk niet de meerderheid.

Dat is geen reden om er niet aan te beginnen. Het is een reden om het om de juiste redenen te doen: een echt probleem oplossen, leren en duurzaam iets opbouwen. En aandacht te besteden aan wat zich niet laat automatiseren: kwaliteit.

De minder goede kant

Afgeraffelde apps komen in review terecht, en iedereen deelt dezelfde wachtrij. Een app in een weekend genereren betekent niet dat hij klaar is: veel inzendingen zijn niet op een apparaat getest en bevatten voorlopige inhoud, zonder privacybeleid of review notes. Andere zijn voor niemand anders dan hun ontwikkelaar interessant. Apple zegt het nochtans al in de inleiding van de guidelines: een app die u alleen aan familie en vrienden wilt laten zien, hoort niet in de App Store; daarvoor zijn Xcode en Ad Hoc-distributie bedoeld. Elk van die inzendingen houdt een reviewer bezig die zich dan niet met de uwe bezighoudt. Door updates van bestaande apps voorrang te geven, beschermt Apple huidige gebruikers en gevestigde ontwikkelaars; de keerzijde is langer wachten voor nieuwe apps.

Spam is het eerste doelwit. Guideline 4.3 verbiedt meerdere varianten van dezelfde app in te dienen en apps zonder wezenlijk verschil in verzadigde categorieën. Met een agent maakt u in één middag vijf klonen; precies dat filtert Apple eruit. Apple zegt de automatisering en misbruikdetectie te hebben versterkt en waarborgen te hebben toegevoegd tegen herhaalde inzendingen met dezelfde onopgeloste problemen. De guidelines zeiden het al: herhaalde afwijzing om dezelfde reden verlengt de review.

Apps die code genereren liggen onder vuur. Apple heeft dit jaar updates geblokkeerd of verschillende vibe-codingapps verwijderd, waaronder Replit, Vibecode en Anything. De reden is niet vibe coding op zichzelf, maar guideline 2.5.2: een app mag geen code downloaden of uitvoeren die zijn functionaliteit na de review verandert.

Meer apps betekent niet meer gebruikers. Bij vrijwel gelijkblijvende downloads vecht elke nieuwe app om dezelfde aandacht. De technische drempel is lager geworden; de kwaliteitslat ligt juist hoger.

Wat dit voor u verandert

• U blijft verantwoordelijk. De guidelines herinneren eraan: alles in uw app, inclusief SDK's van derden, valt onder uw verantwoordelijkheid. « De agent heeft het geschreven » is geen aanvaardbaar argument.
• De kwaliteit van de inzending wordt een voordeel. In een overvolle wachtrij valt een complete app met duidelijke notities nog meer op dan voorheen.
• Eén app, geen vijf varianten. Gebruik in-app aankopen of instellingen voor varianten in plaats van steeds meer bundle IDs.
• Dien nooit opnieuw in zonder iets te corrigeren. Een onnodige extra ronde kost dagen en kan u plaatsen tussen het gedrag waarop Apple let.
• Bouw marge in. Reken voor een nieuwe app op een week, plus een eventuele extra ronde. Als het binnen 48 uur lukt, des te beter.

---

De adviezen die standhouden

Kwaliteit telt, en dat staat in de regels

« Een verzorgde app wordt beter behandeld »: dat klopt, maar niet vanwege het humeur van de reviewer. Sectie 4 van de guidelines zegt het duidelijk: Apple verwacht eenvoudige, verfijnde en gebruiksvriendelijke interfaces. Guideline 4.2 (Minimum Functionality) wijst apps af die niet meer zijn dan een opnieuw verpakte website, een verzameling links of inhoud zonder blijvende waarde.

« Bouw native met SwiftUI »: een goed advies, geen regel

Ik ben native iOS-ontwikkelaar: ik doe het, verdedig het, promoot het en geef er les in. Voor mij is dit de aangewezen manier om een app te bouwen die de conventies van het platform respecteert en volledig benut wat de iPhone en iPad kunnen. Met SwiftUI profiteert u van Dynamic Type, safe areas, sheets, systeemnavigatie en aanpassing aan iPhone en iPad, met directe toegang tot widgets, Live Activities, App Intents en veel meer mogelijkheden van Apples frameworks. Die integratie maakt in het dagelijks gebruik echt verschil en vermindert vanzelf de kleine gebreken die een reviewer opmerkt.

Maar geen enkele guideline verplicht SwiftUI. Een goed gemaakte Expo-, Flutter- of UIKit-app komt probleemloos door de review. Wat wordt afgerekend is het resultaat: een vermomde webview, een interface die stukloopt op een iPad (guideline 2.4.1 moedigt ondersteuning voor iPad aan zodra dat mogelijk is), een toetsenbord dat een veld afdekt. Native vergroot uw kansen op uitmuntendheid; het garandeert die niet.

P.S.: Martin, niet slaan, niet slaan, niet slaaaa… pets

Privacybeleid, support en permissies

Hier onderschatten we de werkelijkheid vaak. Dit zijn geen aanbevelingen, maar verplichtingen:

• Een privacybeleid dat toegankelijk is in App Store Connect én in de app (5.1.1(i)). Het moet beschrijven welke gegevens worden verzameld en waarvoor, derden aan een gelijkwaardig beschermingsniveau binden en uitleggen hoe gegevens worden bewaard en verwijderd en hoe toestemming wordt ingetrokken.
• Een supportlink met actuele contactgegevens, en alle links moeten werken (2.1 en 5.1).
• Duidelijke purpose strings voor elke gevoelige permissie, liefst met een concreet gebruiksvoorbeeld.
• Dataminimalisatie (5.1.1(iii)): geef de voorkeur aan systeemkiezers, zoals de fotokiezer, boven volledige toegang tot de fotobibliotheek.
• Accountverwijdering in de app zodra een account kan worden aangemaakt (5.1.1(v)).

Het vaak aanbevolen formaat « statische HTML » is nergens verplicht. Wat telt, is dat de pagina toegankelijk en actueel is en overeenkomt met wat de app doet.

Sociale apps: vier concrete eisen

Melden, blokkeren, contact, moderatie: dat is precies guideline 1.2 (User-Generated Content), die het volgende vereist:

1. een manier om onacceptabele inhoud vóór publicatie te filteren;
2. een meldmechanisme en een snelle reactie op meldingen;
3. de mogelijkheid om gebruikers die misbruik maken te blokkeren;
4. gepubliceerde contactgegevens waarop u bereikbaar bent.

Sinds de update van 16 oktober 2026 noemt de guideline expliciet apps voor creatie met AI. Apple verduidelijkt dat intieme beelden zonder wederzijdse instemming, ook als ze met AI zijn gegenereerd, actief moeten worden voorkomen en verwijderd. Een ontwikkelaar die geen waarborgen instelt of na een melding niets corrigeert, kan worden geacht de gedragscode te schenden.

De gratis moderatie-API van OpenAI komt vaak terug in gesprekken. Dat is een geldige technische optie, met een belangrijke kanttekening: guideline 5.1.2(i) verplicht u duidelijk te maken wanneer persoonsgegevens met derden worden gedeeld, ook met AI van derden, en expliciete toestemming te verkrijgen. Foto's van uw gebruikers zonder dat te melden naar een extern model sturen, vervangt de ene afwijzing door de andere.

In-app aankopen moeten werken

Vanzelfsprekend, maar vaak mis: guideline 2.1(b) vereist complete, voor de reviewer zichtbare en werkende in-app aankopen. Als een geconfigureerd product niet toegankelijk is in de ingediende build, leg dan in de notities uit waarom. En voorzie een knop « Aankopen herstellen ».

---

Review notes: het meest onderschatte hulpmiddel

Dit is het nuttigste advies van allemaal, en Apple gaat nog verder.

Wat Apple vraagt in de checklist « Before You Submit »:

• volledige toegang tot de app: een actief demoaccount of een volledige demomodus, plus de benodigde hardware of middelen (inloggegevens, voorbeeld-QR-code…);
• een online back-end gedurende de hele review;
• een gedetailleerde uitleg van niet voor de hand liggende functies en in-app aankopen in de notities, indien nodig met documentatie.

Ja, een deel is geautomatiseerd, en bij dit volume is dat normaal. Maar Apple schrijft het zwart op wit in de inleiding van de guidelines: elke app wordt door experts bekeken. In negen van de tien gevallen, zo niet vaker, zit er een mens aan de knoppen, die op het kleine groene (of rode) knopje drukt.

Uw notities zijn dus gericht aan een persoon die uw app in enkele minuten leert kennen. Schrijf ze voor die persoon.

En guideline 2.3.1(a) is ondubbelzinnig: elke nieuwe functie moet nauwkeurig in de notities worden beschreven; algemene beschrijvingen worden afgewezen.

Let op een detail: een demomodus in plaats van een demoaccount wordt alleen geaccepteerd met voorafgaande toestemming van Apple, en alleen als wettelijke of veiligheidseisen verhinderen dat u een account verstrekt.

Een structuur die werkt

U hoeft de roman van iemand anders niet over te schrijven. Dit is het raamwerk dat ik gebruik:

Hallo,

[Naam van de app] is [één zin: wat de app doet, voor wie en welk probleem hij oplost].
Verdienmodel: [gratis / abonnement / eenmalige aankoop], via In-App Purchase.

Toegang:
- Demoaccount: [gebruikersnaam] / [wachtwoord]
  (of: geen account vereist)

Belangrijkste gebruikerspad:
1. …
2. …
3. …

In-app aankopen:
- Waar de paywall verschijnt en hoe u deze in de sandbox test.
- « Aankopen herstellen »: [locatie].

Niet voor de hand liggende functies:
- [Functie]: hoe u erbij komt en wat deze doet.

Gegevens en permissies:
- Welke permissies, wanneer ze worden gevraagd en waarom.
- Gegevens gedeeld met derden (inclusief AI) en toestemming.

Externe diensten:
- [Dienst]: waarvoor die dient (data, authenticatie, betaling, AI, advertenties…).

Regionale verschillen:
- [Geen / welke].

Regelgeving en inhoud van derden:
- [Niet van toepassing / bijgevoegde documenten].

Account en veiligheid:
- Account verwijderen: [pad].
- Melden / blokkeren: [pad] (bij gebruikersinhoud).

Voor de stijl geldt de gouden regel: korte zinnen die begrijpelijk zijn voor iemand die de app voor het eerst ziet. Alleen het « gebruik geen AI » dat je soms leest zou ik nuanceren: een eerste versie laten schrijven door een agent die uw code kent, bespaart echt tijd. Wat telt, is vóór het indienen nalezen en vereenvoudigen.

Een echt voorbeeld: aangeven wat op afstand wordt aangestuurd

Hier is een notitie die ik bij een van mijn apps heb achtergelaten (geanonimiseerd). Het is een bekend scenario: de advertentie-SDK is geïntegreerd, maar advertenties kunnen vóór publicatie niet worden ingeschakeld, omdat AdMob een in een store gepubliceerde app vereist om de « app readiness » te beoordelen. De advertenties staan tijdens de review dus uit via een feature flag.

ADVERTISING DISCLOSURE - INITIAL 1.0 RELEASE
This app includes the Google Mobile Ads (AdMob) SDK and Google UMP consent integration. Production advertising is currently disabled through a remote feature flag. This is the general launch configuration, not a condition targeting App Review. We are disclosing the advertising integration explicitly; it is not disabled to hide it from reviewers.

The reason is that this initial release is not yet publicly available on the App Store. AdMob requires a published, downloadable app linked to a supported store for its app readiness review, and approval before full ad serving. We therefore cannot complete that activation process before publication. After release, we plan to link the App Store listing, complete AdMob's readiness process and enable production advertising through the feature flag.

The absence of ads during review should not be interpreted as an ad-free product. Ad presentation will remain subject to the applicable consent and tracking permissions.
Google's explanation: https://support.google.com/admob/answer/10564477?hl=en

Waarom deze notitie werkt:

• Ze noemt wat in de binary zit: de AdMob SDK en de UMP-toestemmingsmodule.
• Ze vermeldt de feature flag en verduidelijkt dat die niet op de review is gericht. Dat is precies het tegenovergestelde van een slapende functie in de zin van guideline 2.5.19.
• Ze legt uit waarom, met een controleerbare externe bron.
• Ze kondigt aan wat na publicatie verandert, zodat het inschakelen van advertenties geen verrassing is.
• Ze wijst op toestemming: gepersonaliseerde advertenties blijven afhankelijk van trackingtoestemming.

Niets verborgen, niets te interpreteren: de reviewer weet precies wat hij goedkeurt.

De demovideo: niet verplicht, maar steeds vaker gevraagd

Soms leest u dat eerste inzendingen zonder notities of video automatisch worden afgewezen. Niets in Apples documentatie zegt dat. Apple schrijft dat u bereid moet zijn een demovideo of de hardware te verstrekken wanneer bepaalde functies afhangen van een moeilijk na te bootsen omgeving of specifieke hardware.

In de praktijk helpt een korte schermopname met toelichting, als bijlage toegevoegd aan App Review Information, enorm zodra de app afwijkt van het gewone: een verbonden apparaat, geolocatie, een sociale functie waarvoor meerdere accounts nodig zijn. Voor een notitie-app zonder account is het overbodig.

Het doel blijft juist: de review zo eenvoudig mogelijk maken. Een reviewer die uw app in drie minuten begrijpt, heeft geen reden u vragen te stellen.

Wanneer Apple u om « meer informatie » vraagt

Voor nieuwe apps komt een bericht steeds vaker terug: een gestandaardiseerd verzoek om informatie, gekoppeld aan guideline 2.1. Dit ontving ik onlangs voor een van mijn apps:

We need additional information to better understand the app and complete the review.

Reply in App Store Connect with all of the following information and also add this
information to the Notes field of the App Review Information section in App Store
Connect, for reference on future submissions:

1. A screen recording captured on a physical device, running the latest operating
   system, demonstrating the app's functionality. The recording must begin with
   launching the app and show the typical user flow. If the app has any of the
   following, include them in the recording:
   - Account registration, login, and account deletion flows.
   - Any user-generated content, including the required content reporting and
     blocking mechanisms.
   - Accessing paid content or features within the app.
2. A description of the app's purpose and target audience, including the problem
   it solves and the value it provides
3. Instructions for setting up and accessing the app's main features, including
   any required login credentials or sample files
4. A list of the external services, tools, or platforms the app uses to deliver
   its core functionality (for example, data providers, authentication services,
   payment processors, or AI services)
5. Describe any regional differences in the app's features or content, or confirm
   that the app functions consistently across all regions
6. If the app operates in a highly regulated industry or includes protected
   third-party material, provide any relevant documentation or credentials to
   demonstrate you are authorized to provide these services or protected material

Het bericht herinnert terloops aan de klassieke valkuilen: bugs op een fysiek apparaat, een demoaccount, schermafbeeldingen die de app in gebruik tonen, in-app aankopen die met de app zijn geconfigureerd en distributie die voor bedrijven is gereserveerd.

En hier is mijn antwoord, geanonimiseerd:

1. [Screen recording attached, captured on a physical device.]

2. [App] is a [category] app that [what the app does]. It's inspired by
   [well-known reference], but adds [its own distinctive features]. It's designed
   for [target audience], and [the problem it solves / the value it provides].

3. There's no account to create and no login required. Users can simply open the
   app and start using it. The main flow consists of [main interaction]. Users
   can also [secondary features] directly from the app. The app includes optional
   rewarded ads to unlock [optional extra].

4. The app runs primarily on the device. [Core processing] is handled locally,
   so there's no external API involved in the core functionality. Google's AdMob
   is used to display advertisements, including optional rewarded ads.

5. The app works the same way in every region where it's available. The main
   difference is the language: the app has a localized name and content adapted
   to each language. Features and core mechanics remain consistent across all
   supported regions.

6. Not applicable. [App] is an original app and doesn't operate in a regulated
   industry.

Drie lessen:

• De video is niet standaard verplicht, maar wordt hier expliciet gevraagd, opgenomen op een fysiek apparaat met de nieuwste versie van iOS, vanaf het opstarten van de app. Bereid die dus maar beter vóór de eerste inzending voor.
• Apple vraagt deze antwoorden toe te voegen aan het veld Notes, voor volgende inzendingen. Anders gezegd: als ze daar vanaf het begin hadden gestaan, was die extra ronde waarschijnlijk vermeden.
• De zes vragen vormen een uitstekende checklist. Doel, publiek, toegang, externe diensten, regionale verschillen, regelgeving: ik heb ze opgenomen in het bovenstaande model voor notities.

---

Wat u niet moet doen (en waarom het soms erger is dan een afwijzing)

Schermen met « binnenkort beschikbaar »

Voorlopige inhoud, knoppen die niets doen, lege links: dat is de kern van guideline 2.1 en volgens Apple de belangrijkste oorzaak van problemen. Verwijder de functie liever uit de build dan haar half af te tonen.

De paywall na de review aanpassen

Soms wordt « een op afstand beheerde paywall na de review in strijd met de regels maken » bij gewone dark patterns ingedeeld. Dat is veel ernstiger.

Guideline 2.5.19, op 16 oktober 2026 toegevoegd om specifiek bait-and-switch aan te pakken, verbiedt verborgen, slapende of ongedocumenteerde functies en voorziet in verwijdering van de app en beëindiging van het ontwikkelaarsaccount. De inleiding van de guidelines is nog directer: proberen het reviewproces te misleiden leidt tot verwijdering van de apps en uitsluiting van het Apple Developer Program. Het is geen gok op de coulance van een reviewer, maar een risico voor uw hele onderneming.

Uw paywall op afstand configureren is niet verboden. Hem laten omschakelen naar iets wat de reviewer niet heeft gezien, wel.

Verzoeken om een beoordeling

Guideline 5.6.1 verplicht de door Apple verstrekte API te gebruiken om een beoordeling te vragen en verbiedt aangepaste prompts. Guideline 3.2.2(x) verbiedt de toegang tot een functie afhankelijk te maken van een beoordeling van de app.

Tijdens onboarding om een beoordeling vragen is niet expliciet verboden, maar wel absurd: de gebruiker heeft nog niets gezien en het systeem beperkt hoe vaak zo'n verzoek wordt getoond. Wacht op een echt moment van tevredenheid.

Vals sociaal bewijs en onbewezen beloften

Een verzonnen « 1 miljoen gebruikers », nepbeoordelingen, « lost 100% van uw problemen op »: guideline 5.6.3 verbiedt elke manipulatie van beoordelingen, ranglijsten of zoekresultaten, en 2.3.7 verbiedt onbewezen beweringen in metadata. Voor gezondheidsapps vereist 1.4.1 documentatie van de methodologie achter elke claim over nauwkeurigheid.

Een app kopiëren

Vanzelfsprekend, en Apple gaat verder. Guideline 4.1 wijst kopieën af, en het zich voordoen als een andere app is een schending van de gedragscode. 4.3 sluit verzadigde categorieën uit (zaklampen, achtergronden, datingapps, eenvoudige timers…), tenzij de ervaring echt anders is. Er bestaan al een miljoen scheetkastjes, zaklampen en datingapps: Apple noemt scheet- en boerapps zelfs expliciet als apps die niets toevoegen aan de App Store.

Retentieaanbiedingen: gebruik de officiële hulpmiddelen

Er wordt veel gesproken over « transaction abandon » en « exit offers » (een aanbod doen aan iemand die twijfelt of wil opzeggen). Deze praktijken zijn op zichzelf niet verboden, en StoreKit biedt er officiële mechanismen voor: promotionele aanbiedingen, terugwinacties (win-back offers) en het systeemscherm voor abonnementsbeheer.

Ze bewaren voor een latere update is verstandig: minder oppervlak, minder vragen. Maar de echte regel ligt elders. Guideline 3.1.2(c) vereist dat duidelijk wordt beschreven wat de gebruiker voor de prijs krijgt, en 5.6 verbiedt gebruikers tot ongewenste aankopen aan te zetten. Een helder aanbod dat in de notities wordt beschreven, heeft niets te vrezen. Een aanbod dat de prijs verhult, wel.

---

Beëindigde accounts: begrijpen hoe u voorkomt dat het u overkomt

Een afwijzing kost een paar dagen. Een beëindiging kost u al uw apps. Het onderwerp houdt sociale media de afgelopen weken sterk bezig en verdient een rustige bespreking.

Waarom Apple de teugels aantrekt

Op 16 oktober 2026 heeft Apple zijn guidelines op twee punten aangescherpt: intieme beelden zonder wederzijdse instemming, ook als ze met AI zijn gegenereerd, die apps moeten voorkomen en verwijderen (1.2), en bait-and-switch: apps die zich tijdens de review onschuldig voordoen en na goedkeuring schadelijke functies activeren (2.5.19). In dezelfde aankondiging zegt Apple vorig jaar te hebben voorkomen dat meer dan 150.000 apps met veiligheidsproblemen gebruikers bereikten en meer dan 193.000 ontwikkelaarsaccounts te hebben beëindigd wegens fraude en misbruik.

Deze cijfers zeggen genoeg: fraude in de App Store is grootschalig en georganiseerd. Het aantal « nudification »-apps is sterk gegroeid, instanties zoals de stad San Francisco hebben verwijdering geëist en de stroom AI-gegenereerde inzendingen verhoogt de druk verder. Dat het vertrouwen van gebruikers in de App Store desondanks standhoudt, is grotendeels aan dit werk te danken.

Op deze schaal raken ook ontwikkelaars te goeder trouw soms verstrikt in het net. Juist voor die gevallen bestaat het beroep bij de App Review Board.

Wat ontwikkelaars beschrijven

De gedeelde meldingen beroepen zich op sectie 3.2(f) van de Developer Program License Agreement en noemen een « patroon van manipulatief of misleidend gedrag », gevolgd door een lijst mogelijke gedragingen: onjuiste metadata, misleidende inhoud, nepbeoordelingen, misleidende antwoorden aan support of in App Store Connect, aankopen via bait-and-switch…

Phillip Shoemaker, die App Review heeft geleid, publiceerde eind oktober zijn analyse. Hij denkt dat de geschiedenis van afwijzingen inmiddels zwaar meeweegt: het aantal inzendingen, naamswijzigingen en herhaalde afwijzingen wegens onacceptabele inhoud, vooral bij generatieve foto-apps. Hij erkent ook de moeilijkheden aan Apples kant: generatieve apps zijn heel lastig te beoordelen, een correctie op de server kan op elk moment worden teruggedraaid en Apple verbindt accounts met elkaar, waardoor het een overzicht heeft dat de ontwikkelaar niet altijd heeft. Zijn voorstellen zijn constructief: specifiekere afwijzingen over wat moet veranderen en concrete informatie in de meldingen, zodat beroep zinvol is.

Wie te slim wil zijn, komt zichzelf tegen

Namen noemen is niet nodig: de verhalen die rondgaan lijken op elkaar. En wie ze aandachtig leest, ziet vaak dezelfde reflexen. Ze komen zelden voort uit slechte bedoelingen, maar gezien vanuit Cupertino lijken ze verdacht veel op wat Apple probeert op te sporen:

• Steeds opnieuw indienen en telkens een detail wijzigen, « om te kijken of het lukt ».
• De app hernoemen, onderweg van concept of categorie veranderen, soms meerdere keren.
• Oppervlakkig corrigeren: een optie uit een menu verwijderen terwijl de functie op een andere manier bereikbaar blijft.
• Een schakelaar op de server behouden die de reviewer nooit heeft gezien.
• Zoekwoorden opstapelen, of iets te veel inspiratie halen uit de naam van een concurrerende app.
• Meerdere accounts gebruiken of het eigen account uitlenen om een afwijzing te omzeilen.
• De waarheid naar uw hand zetten in antwoorden aan App Review.

Afzonderlijk kan elk van deze handelingen onschuldig lijken. Samen vormen ze een patroon. En bij honderdduizenden inzendingen per week is dat patroon wat Apple leest, niet uw bedoelingen.

De moraal is eenvoudig: slimmer proberen te zijn dan App Review is wedden tegen het huis. En het huis kent de volledige geschiedenis.

De App Review Board blijft er om fouten recht te zetten, en ontwikkelaars te goeder trouw krijgen er gelijk. Maar het beste beroep is het beroep dat u nooit hoeft in te stellen.

Wat dit voor u verandert

Ik ga niet voor jurist spelen: bij een beëindiging is beroep bij de App Review Board de enige weg, en in de gemelde gevallen geeft de kennisgeving daarvoor een termijn van 30 dagen. Als het u overkomt, laat u dan begeleiden. Enkele gewoonten verkleinen het risico daarentegen aanzienlijk:

• Uw afwijzingsgeschiedenis telt. Elke inzending laat een spoor achter. Dien nooit opnieuw in « om te zien »: stel vóór het corrigeren een concrete vraag in App Store Connect.
• Verander de identiteit van de app onderweg niet. Naam, concept, categorie: herhaalde wijzigingen lijken op wat Apple probeert op te sporen. Als App Review erom vraagt, laat het dan schriftelijk bevestigen in App Store Connect, ook na een telefoongesprek, en vat schriftelijk samen wat telefonisch is gezegd.
• Stop met opnieuw indienen als een afwijzing zich blijft herhalen. Vraag schriftelijk om de volledige lijst van knelpunten en stel vervolgens beroep in bij de App Review Board in plaats van poging na poging te doen.
• Documenteer alles wat op afstand configureerbaar is. Feature flags, paywall, AI-modellen: vermeld het in de notities en laat zien wat kan veranderen.
• Corrigeer bij een generatieve app bij de bron. Een optie uit een menu verwijderen is niet genoeg als het model de inhoud nog steeds op een eenvoudige prompt produceert. De filtering moet daadwerkelijk werken, bij het model én bij de uitvoer.
• Antwoord nauwkeurig in App Store Connect. « Misleidende antwoorden » staan expliciet op de lijst met redenen.
• Bewaar een archief van elke inzending. Build, notities, schermafbeeldingen, uitwisselingen met App Review: dat is uw enige dossier bij een beroep.
• Let op met wie u omgaat. Gedeelde accounts, uitgeleende certificaten, partners met twijfelachtige praktijken: Apple verbindt accounts met elkaar.

Daarom volg ik ook niet het soms geopperde idee dat « Apple zou willen dat we de grens opzoeken ». In 2026 telt elke inzending mee in uw geschiedenis. Mik liever op duidelijkheid dan op de grens.

---

Een review versnellen: wat er werkelijk bestaat

Hierover doen de meeste misvattingen de ronde.

De versnelde review (expedite)

Die bestaat voor uitzonderlijke omstandigheden: een kritieke bug of een release gekoppeld aan een evenement waarbij u rechtstreeks betrokken bent. Enkele vaak vergeten details:

• alleen een inzending die al voor review is ingediend, kan worden versneld;
• vermeld bij een kritieke bug in de notities de stappen om die in de huidige versie te reproduceren;
• vermeld bij een evenement het evenement, de datum en de relatie van de app ermee;
• Apple behandelt het verzoek afhankelijk van beschikbaarheid en vraag, zonder garantie;
• en vooral: bij misbruik behoudt Apple zich het recht voor toekomstige verzoeken af te wijzen.

« U hoeft geen reden op te geven » is dus misleidend: het formulier is eenvoudig, maar de toelichting moet in de notities staan. Een « viraal moment » of « marketing » staat niet bij de criteria. Daarvoor zou ik deze kans niet verspillen.

Het telefoongesprek met Apple: geen snelle wachtrij

Het gesprek wordt vaak voorgesteld als een weinig bekende methode om in een aparte wachtrij te komen. Dat is niet wat Apple beschrijft.

U kunt vanuit het antwoordvenster van App Review, na een eerste antwoord van hun kant, een gesprek met een Apple-medewerker aanvragen en uw tijdzone en taal opgeven. Deze gesprekken vinden doorgaans binnen drie tot vijf werkdagen plaats. Het is een uitstekend hulpmiddel om een misverstand over een afwijzing op te lossen. Het is geenszins een sluiproute naar 48 uur. Houd er rekening mee dat de volgende review door iemand anders kan worden uitgevoerd: laat de conclusies altijd schriftelijk bevestigen in App Store Connect.

App Review-afspraken: het echte geheim

Wat zelden wordt genoemd en wat ik al mijn klanten vóór een lastige eerste inzending aanbeveel: App Review-afspraken via Meet with Apple. Dertig minuten videobellen met een App Review-expert, op dinsdag en donderdag afhankelijk van beschikbaarheid, om concrete vragen te stellen over hoe een guideline op uw app van toepassing is.

Twee beperkingen om te kennen: de afspraak is informatief, vervangt of versnelt de review niet en garandeert die evenmin, en Apple keurt geen enkele functie vooraf goed. Maar indienen terwijl u al weet hoe Apple uw situatie beoordeelt, is de best mogelijke investering.

Uit de lus van opeenvolgende afwijzingen komen

De nachtmerrie is bekend: een afwijzing, een correctie en vervolgens een nieuwe afwijzing om een andere reden. Om eruit te komen moet u wel de juiste kanalen gebruiken:

• Antwoord in App Store Connect met een concrete vraag: over de functie, guideline of stap die verduidelijking behoeft. Een specialist die uw app kent, antwoordt. Vragen « zijn er nog andere knelpunten? » is terecht, ook al kan niemand u dat garanderen.
• Bug Fix Submission: bij een al gepubliceerde app wordt een update die bugs oplost niet geblokkeerd door andere problemen met guidelines, behalve bij een juridisch of veiligheidsprobleem. De rest corrigeert u bij de volgende inzending.
• Beroep bij de App Review Board als u vindt dat de app verkeerd is begrepen: eenmaal per afgewezen inzending, met concrete argumenten.

Wat de toon betreft, herinnert guideline 5.6 eraan iedereen respectvol te behandelen, ook in het contact met Apple. Klagen helpt niet; argumenteren aan de hand van de guidelines wel.

---

Scope creep: het beste advies, met een nuance

« Dien een MVP in » is uitstekend advies, en Apple bevestigt het op zijn manier: een complexe app of een app die nieuwe vragen oproept kan een grondiger onderzoek vereisen, en herhaalde afwijzingen op basis van dezelfde guideline verlengen de review.

De beschrijving van « twee stapels », met escalatie naar een senior specialist en 14 dagen wachttijd, is daarentegen nergens gedocumenteerd. Wat Apple wel documenteert, zijn gereguleerde sectoren die meer documenten en tijd vragen:

• apps voor bankieren, financiën, gezondheid, kansspelen, crypto of luchtvaart moeten worden ingediend door de rechtspersoon die de dienst aanbiedt (5.1.1(ix));
• voor kansspelen moet extra tijd worden voorzien (5.3);
• medische apps of apps met gelicentieerde inhoud moeten de bijbehorende vergunningen verstrekken.

Tot slot een nuance: een MVP is geen magere app. De ondergrens van guideline 4.2 geldt vanaf de eerste versie. Verminder het aantal functies, niet de afwerking ervan.

---

Samengevat: waar, te nuanceren, onwaar

---

Mijn checklist vóór indiening

Volledigheid (2.1)

• Getest op apparaten, nieuwste iOS-versie, iPhone en iPad
• Geen voorlopige inhoud, geen dode links
• Back-end online, geldig demoaccount
• In-app aankopen zichtbaar, werkend in sandbox, herstel beschikbaar

Informatie voor de review

• Notities: wat de app doet, belangrijkste gebruikerspad, niet voor de hand liggende functies, aankopen
• Actuele contactgegevens in App Review Information
• Video of documenten toegevoegd als de omgeving moeilijk na te bootsen is

Privacy en veiligheid (5.1, 1.2)

• Privacybeleid in App Store Connect en in de app
• Nauwkeurige purpose strings, waar mogelijk systeemkiezers
• Delen met derden (inclusief AI) aangekondigd en met toestemming
• Accountverwijdering in de app
• Bij gebruikersinhoud: filteren, melden, blokkeren, contact

Metadata (2.3)

• Schermafbeeldingen die de app in gebruik tonen
• Geen onbewezen beloften, geen vals sociaal bewijs
• Betaalde aankopen duidelijk aangegeven

Strategie

• Eerste versie beperkt tot de kern, geavanceerde aanbiedingen in een latere update
• Minstens een week marge vóór de lanceringsdatum van een nieuwe app
• Archief van elke inzending: build, notities, schermafbeeldingen, uitwisselingen met App Review
• App Review-afspraak gemaakt als een guideline vragen oproept

---

Het echte geheim: saai en eerlijk zijn

Soms leest u dat Apple zou willen dat we de grens opzoeken. Daar ben ik het niet mee eens. De guidelines zijn een levend document en Apple erkent dat er ruimte is voor beoordeling. Maar de inleiding is duidelijk: het uitgangspunt is een veilige ervaring voor gebruikers, en elke poging om de review te misleiden komt u duur te staan.

Verder is men het over één regel eens: wees duidelijk, wees eerlijk, leg uit wat u doet en laat het zien. Een volledige, begrijpelijke inzending zonder verrassingen komt binnen de normale termijnen door de review. Voor een update is dat vaak minder dan 48 uur. Reken voor een nieuwe app in 2026 liever op een week en laat u aangenaam verrassen.

Nu agents iedereen in staat stellen om in een weekend een app in te dienen, wordt App Review weer wat het in het begin was: een filter. En dat is goed. Dankzij dat filter kan een gebruiker een onbekende app zonder wantrouwen installeren, en dat vertrouwen bepaalt de waarde van de App Store voor ons ontwikkelaars. De App Review-teams behandelen honderdduizenden inzendingen per week; hun werk makkelijker maken maakt ook ons eigen leven makkelijker.

Dan kunt u maar beter aan de goede kant van het filter staan.

---

Ik maak en publiceer apps sinds de geboorte van de App Store, voor mezelf, voor startups of voor huizen met een winkel op de Champs-Élysées. Als u een lastige eerste inzending, een sociale app, een abonnementsmodel of een app in een gereguleerde sector voorbereidt, is dat het soort begeleiding dat ik met BNC Consulting aanbied. Schrijf me.

Contact opnemen

En om er onder ontwikkelaars over te praten: sluit u aan bij de community ⌘+F. Verhalen over afwijzingen delen we ook tijdens meetups, bij een kop koffie of een diner.

Tot slot een dikke knuffel voor Raph’, Anders, Erica, Ewelina en al mijn andere vrienden in het App Review-team, die bijzonder moeilijk werk doen. Nog een voor Martin, Mac, SiQing en de WWDR-teams, die vaak als buffer dienen — en voor alle anderen over de hele wereld die ik ken maar hier niet kan noemen.

Dank dat jullie er zijn om gebruikers te beschermen. Ook dat is de goede kant van de App Store.

— Clément

---

Officiële bronnen (geraadpleegd op 1 november 2026)

• App Review — Apple Developer
• App Review Guidelines (bijgewerkt op 16 oktober 2026)
• Een versnelde review aanvragen
• Contact opnemen met App Review en een gesprek aanvragen
• Een App Review-afspraak aanvragen

Gegevens en pers

• MobileGamer.biz — reviewtijden en toestroom van AI-gegenereerde apps (20 oktober 2026, met Apples antwoord en cijfers)
• 9to5Mac — stijging van 84% in nieuwe apps
• TweakTown — 560.000 nieuwe apps in het eerste halfjaar van 2026
• RevenueCat — State of Subscription Apps 2026
• iPhoneSoft — AppReviewTimes sluit zijn deuren (maart 2019)
• Apple — Strengthening App Review Guidelines against nonconsensual intimate imagery and bait-and-switch apps (16 oktober 2026)
• Phillip Shoemaker — Apple approved the fix. Then it called the developer a liar. (30 oktober 2026)
• 9to5Mac — nieuwe regels tegen nudification en bait-and-switch

---

Zoals gewoonlijk is dit artikel met de hand in het Frans geschreven. De Nederlandse vertaling en illustraties zijn gemaakt met de tools van OpenAI.