App Store-afwijzing oplossen: richtlijn voor richtlijn uitgelegd (2026)

Een App Store-afwijzing is een bericht van App Review dat een richtlijn noemt, beschrijft wat de reviewer zag en de release tegenhoudt totdat je het probleem oplost, toelicht of er bezwaar tegen maakt. Begin met het omzetten van dat bericht in een probleem dat je kunt testen. De volgende stap hangt ervan af of de reviewer de app niet kon gebruiken, een strijdigheid met het beleid vond of meer informatie nodig heeft. Per oktober 2026 zijn de App Review Guidelines voor het laatst bijgewerkt op 16 oktober 2026, dus controleer de actuele nummering voordat je een sectie citeert.

Wat vertelt een App Store-afwijzing je eigenlijk?

Een afwijzingsbericht van de App Store noemt de richtlijn die de reviewer heeft toegepast, beschrijft het specifieke gedrag dat de reviewer zag en somt de vervolgstappen op. Vaak staan ook het apparaat, de iOS-versie en screenshots erbij.

Bewaar het volledige bericht, alle screenshots, het buildnummer en de apparaatgegevens. Lees de genoemde sectie op de actuele richtlijnenpagina. Schrijf daarna één zin: "De reviewer kon X niet voltooien omdat Y." Vraagt het bericht om ontbrekende informatie in plaats van een defect te melden, noteer dan precies wat er ontbreekt. Apples standaardtekst bij 2.1 vertelt je ook hoe je het probleem reproduceert: "Verwijder bij nieuwe apps alle eerdere versies van je app van een apparaat, installeer de app en volg daarna de stappen om het probleem te reproduceren."

• Noemt het bericht een crash, een onbereikbaar scherm of een onvolledige functie? Reproduceer die flow in de ingediende release-build, op het type apparaat dat Apple noemde.
• Noemt het screenshots, de beschrijving of de review notes? Controleer of je het alleen in de metadata kunt oplossen.
• Noemt het betalingen, inloggen, privacy of minimale functionaliteit? Vergelijk het gedrag van het product met de genoemde richtlijn.

Welke richtlijnen noemen App Store-afwijzingen en wat eisen ze?

Elke richtlijn stelt een concrete eis, dus koppel het genoemde nummer aan de bijbehorende tekst en test tegen precies die tekst. De tabel citeert de huidige tekst van de richtlijnen die in afwijzingsberichten vaak worden genoemd.

De update van 16 oktober 2026 voegde 2.5.19 toe voor verborgen, slapende of ongedocumenteerde functies, die eerder onder 2.3.1 vielen. Ook kwam er 2.3.14 bij over creatieve assets en is het Music Streaming Services-entitlement opgegaan in het StoreKit External Purchase Link-entitlement onder 3.1.1(a). Zie de tabel als vertrekpunt, niet als gegarandeerde oplossing. Eén richtlijn kan verschillende problemen dekken, en het voorbeeld van de reviewer is de concrete situatie die je moet oplossen.

Hoe los je een 4.2-afwijzing wegens minimale functionaliteit op?

Je lost een 4.2-afwijzing op door echte app-waarde toe te voegen, niet door de beschrijving te herschrijven. Richtlijn 4.2 zegt: "Als je app niet bijzonder nuttig, uniek of 'app-achtig' is, hoort hij niet in de App Store."

Vraag je af wat iemand in je app kan doen dat hem als app nuttig maakt. Misschien kan iemand een workflow afronden, betekenisvolle gegevens opslaan, apparaatfuncties gebruiken op een manier die bij de app past, of een mobiele ervaring krijgen die voor het apparaat is gebouwd. Geen enkele gepubliceerde lijst met functies garandeert goedkeuring. Bestaan die workflows al, beschrijf ze dan in de review notes met exacte stappen en screenshots. Toont de app vooral een webpagina, dan is er productwerk nodig. Notificaties of een leeg instellingenscherm toevoegen om native te lijken, vervangt geen echte waarde voor gebruikers.

Hoe antwoord je App Review in App Store Connect?

Antwoord in App Store Connect: open de inzending via de link naar onopgeloste problemen van de app, klik op Resolve en klik daarna op Reply to App Review. Volgens Apples helppagina heb je hiervoor de rol Account Holder, Admin of App Manager nodig.

1. Selecteer de app in Apps.
2. Klik bovenaan de pagina op de link die aangeeft dat er onopgeloste problemen zijn.
3. Klik in de sectie In Progress op Resolve naast de inzending.
4. Klik op Reply to App Review en voer je tekst in.
5. Wil je screenshots of documenten meesturen, klik dan op Attach File en daarna op Reply.

Apple zegt dat je kunt corresponderen en bestanden kunt bijvoegen "totdat je opnieuw indient bij App Review", dus stuur je bewijs voordat je opnieuw indient. Houd het antwoord kort en feitelijk: zeg wat er is veranderd, waar het zit en hoe de reviewer het kan controleren. Ga niet in discussie over andere apps die hetzelfde lijken te doen.

Moet je de metadata aanpassen, een nieuwe build uploaden of bezwaar maken?

Pas de metadata aan en dien dezelfde build opnieuw in als alleen de vermeldingsgegevens onjuist waren. Upload een nieuwe build als het gedrag van de app moet veranderen. Maak alleen bezwaar als je ervan overtuigd bent dat de app al aan de richtlijn voldoet.

Apples richtlijnen voor bezwaar vragen je om "punt voor punt uit te leggen hoe je app voldoet aan" de richtlijn. Er staat ook dat je geen bezwaar moet maken nadat je de problemen al hebt opgelost en opnieuw hebt ingediend. Een volledig bezwaar "garandeert niet" dat de beslissing wordt teruggedraaid. Voor apps die al in de store staan, zegt het Bug Fix Submissions-beleid in de richtlijnen dat bugfixes niet worden vertraagd vanwege richtlijnovertredingen, "behalve als die verband houden met juridische of veiligheidskwesties".

Hoe hebben andere ontwikkelaars echte App Store-afwijzingen opgelost?

In openbare forumdiscussies kwamen veel 2.1-afwijzingen voort uit verschillen tussen de omgeving van de reviewer en die van de ontwikkelaar: een ander netwerk, apparaat of andere toestemmingsstatus. Een 4.2-afwijzing is een productprobleem, dus kleine aanpassingen lossen die zelden op.

Inlogfout onder 2.1. Een ontwikkelaar op de Apple Developer Forums citeerde het bericht "Specifically, we were not able to log in due to an error" ("we konden namelijk niet inloggen door een fout"), terwijl de live- en TestFlight-versie met dezelfde inloggegevens wel inlogden. Andere ontwikkelaars in de discussie meldden verschillende oplossingen. De een loste het op door "http te veranderen in https op de webserver". Een ander voegde na drie afwijzingen een status "Controleer je verbinding" toe in plaats van een eindeloze laadindicator. Een derde haalde na vijf afwijzingen iPad uit het deployment target, wat het probleem omzeilt door iPad-ondersteuning te schrappen.

Crash bij het opstarten. Op het Solar2D-forum kreeg een ontwikkelaar te horen "We were unable to review the app because it crashed on launch" ("we konden de app niet beoordelen omdat hij crashte bij het opstarten") op een iPhone 13 mini met iOS 18.3.2. Het bijgevoegde crashlog toonde een ontbrekende NSUserTrackingUsageDescription-sleutel. De ontwikkelaar bevestigde: "Hij werd goedgekeurd na het toevoegen van: NSUserTrackingUsageDescription."

WebView-app onder 4.2. Een ontwikkelaar op de Apple Developer Forums meldde een tiende afwijzing voor een app op basis van WebView. De reviewer had een screenshot van het linkermenu gestuurd met de opmerking dat er content ontbrak. De hoofdschermen waren inmiddels native, maar twee of drie schermen openden nog een WebView. Het antwoord dat als oplossing was gemarkeerd, kwam van App Review en raadde een een-op-een App Review-consultatie aan. De discussie bevestigt geen goedkeuring.

De vergelijking: de 2.1-gevallen werden opgelost door de omstandigheden van de reviewer na te bootsen en het crashlog te lezen. Het 4.2-geval liep vast omdat elke nieuwe inzending maar een deel veranderde van een app die nog steeds grotendeels een website was.

Hoe voorkom je dat dezelfde afwijzing opnieuw gebeurt?

Maak van elk opgelost probleem een punt op je releasechecklist en test het opnieuw in de release-build vóór elke inzending. Apples richtlijnen waarschuwen dat de review "langer duurt" als een app herhaaldelijk wordt afgewezen voor dezelfde richtlijnovertreding.

• Verwijder de app en installeer de release-build daarna opnieuw op een fysieke iPhone en iPad.
• Log in met het review-account op een netwerk zonder ontwikkelservers of HTTP-uitzonderingen.
• Open elke toestemmingsprompt en controleer of elke usage description in Info.plist aanwezig is.
• Zorg dat elke in-app-aankoop is ingediend, zichtbaar is en wordt toegelicht in de review notes.
• Werk de review notes bij zodra een flow verandert. Plak geen notes van zes releases geleden.

Volg bij 2.1-problemen het testplan voor de release-build bij 2.1-afwijzingen en richt een demo-account voor reviewers in. Loop daarna de checklist voor inzendingen door voor de volgende build. Kom je met het reviewbericht nog steeds niet verder, stuur ons dan de details en we helpen je uitzoeken of het ontbrekende stuk in de toegang, de metadata of de code zit.