App Review Guidelines oktober 2026: wat 1.2, 2.3.14, 2.5.19 en 3.1.1(a) betekenen voor je app

De wijzigingen in de App Review Guidelines van oktober 2026 werden aangekondigd in Apples bericht Updated App Review Guidelines are now available op 16 oktober 2026. Twee richtlijnen zijn nieuw (2.3.14 en 2.5.19), drie passages zijn herschreven (1.2, 3.1.1(a) en sectie 5), en de secties Before You Submit en After You Submit kregen links naar extra documentatie. Hieronder vind je elke wijziging in begrijpelijke taal, wie actie moet ondernemen en een checklist voor je volgende inzending.

Wat veranderde er op 16 oktober 2026 in de App Review Guidelines?

Apple voegde richtlijn 2.3.14 toe voor creative assets en richtlijn 2.5.19 voor verborgen functies. Daarnaast verduidelijkte Apple 1.2 (door gebruikers gegenereerde content), 3.1.1(a) (externe aankooplinks) en sectie 5 (Legal). Apples changelog somt de aanpassingen zo op:

Apple zegt dat vertalingen "binnen een maand beschikbaar zijn op de Apple Developer-website". Raadpleeg per oktober 2026 de Engelse App Review Guidelines wanneer een vertaalde versie daarvan afwijkt.

Wat vereist de nieuwe richtlijn 2.5.19 over verborgen functies?

Richtlijn 2.5.19 vereist dat elke functie in je binary zichtbaar en gedocumenteerd is voor zowel gebruikers als App Review. Functionaliteit verbergen, ook via obfuscatie, kan leiden tot verwijdering van de app en beëindiging van het developeraccount.

De letterlijke tekst, vertaald: "Neem geen verborgen, slapende of ongedocumenteerde functies op in je app; de functionaliteit van je app moet duidelijk zijn voor eindgebruikers en App Review. Pogingen om ongedocumenteerde functies in je app-binary te verbergen, bijvoorbeeld via code-obfuscatie of andere methoden, zijn grond voor verwijdering van je app uit de App Store en beëindiging van je developeraccount." Apple noemt dit al lang bestaand beleid, maar het stond eerder in 2.3.1. De huidige 2.3.1(a) vereist nog steeds dat nieuwe functies "specifiek worden beschreven in de sectie Notes for Review". Afwijzingen wegens verborgen functies zouden nu naar 2.5.19 moeten verwijzen.

In de praktijk: vermeld in je review notes elke functie die via een serverschakelaar, een uitnodigingscode, een QR-scan, een regio of een accountniveau kan worden ingeschakeld. Als een flag een functie pas na goedkeuring activeert, zet die dan aan in de build die wordt beoordeeld, of laat de code weg tot de versie waarin de functie live gaat.

Welke apps worden geraakt door de wijzigingen in richtlijn 1.2?

Richtlijn 1.2 geldt nu voor elke app waarmee gebruikers content kunnen "maken, genereren, uploaden, delen of op een andere manier bijdragen", en noemt sociale media, UGC-platforms en AI-apps voor contentcreatie bij naam. Die apps moeten aanstootgevend materiaal filteren, een meldfunctie met tijdige reacties bieden, gebruikers in staat stellen misbruikende gebruikers te blokkeren en contactgegevens publiceren.

De herziene tekst noemt "niet-consensuele intieme beelden" naast inbreuk op intellectueel eigendom en pesten. Er staat ook: "Developers die geen passende waarborgen implementeren of vastgestelde overtredingen na een melding niet herstellen, kunnen worden geacht de Developer Code of Conduct te schenden." Ook een AI-beeld- of avatarapp die alleen content voor de gebruiker zelf genereert, kan nu onder de regel vallen. Filtering van prompts en output, een meldfunctie en gepubliceerde contactgegevens horen in de build die je indient, niet op een roadmap.

Wat zegt richtlijn 2.3.14 over creative assets?

Richtlijn 2.3.14 zegt dat creative assets betrekking moeten hebben op de content, functionaliteit of het merk van je app, de gewone metadataregels moeten volgen en geschikt moeten zijn voor alle leeftijden. De richtlijn verbiedt ongepaste content, misleidende verwijzingen naar andere apps, niet-verifieerbare claims en "specifieke of afgeprijsde prijsinformatie".

Creative assets zijn de beeld- en video-assets die Apple op 5 oktober 2026 introduceerde. Volgens Apples App Store asset best practices verschijnen ze "in iOS 27 en iPadOS 27 en later, onder meer op je productpagina, in zoekresultaten en wanneer je app wordt uitgelicht". Diezelfde pagina gaat verder dan de richtlijn. Daar staat dat je websiteadressen, copyrightsymbolen, logo's van andere platforms en Apple-onderscheidingen zoals "Editor's Choice" moet weglaten. Ook staat er dat assets "moeten voldoen aan een leeftijdsclassificatie van 4+, zelfs als de classificatie van je app hoger is". Een header met "50% korting deze week" of "#1 budgetapp" overtreedt 2.3.14.

Wat veranderde er in richtlijn 3.1.1(a) over externe aankooplinks?

Richtlijn 3.1.1(a) heeft geen apart bulletpunt meer voor het Music Streaming Services Entitlement. Dat entitlement valt nu onder het bulletpunt StoreKit External Purchase Link Entitlements, en de tekst zegt dat links naar "een toegestane bestemming" mogen gaan. Goedgekeurde bestemmingen kunnen per regio verschillen.

De regels over waar links zijn toegestaan, zijn in deze update niet veranderd. De entitlements blijven beperkt tot specifieke storefronts. De Amerikaanse storefront blijft de uitzondering waar knoppen, externe links en andere calls-to-action zonder entitlement zijn toegestaan. Gebruik je al een van beide entitlements, controleer dan of je link nog steeds uitkomt bij een bestemming die is toegestaan in elke storefront waarin je app beschikbaar is.

Hoe lossen developers afwijzingen wegens verborgen functies en UGC in de praktijk op?

Openbaar gemelde gevallen laten zien dat afwijzingen onder de oude formulering van 2.3.1 over verborgen functies en onder 1.2 meestal werden opgelost door elke functie en elke waarborg makkelijk vindbaar te maken voor de reviewer, of door in beroep te gaan. Alleen codewijzigingen losten ze zelden op.

• In maart 2026 meldde een developer op de Apple Developer Forums dat een native sociale wekkerapp was afgewezen onder "Guideline 2.3.1(a) - Hidden Features" en 4.2. Volgens de developer werden WebViews alleen gebruikt voor het privacybeleid, de voorwaarden en de FAQ, en ging die in beroep. App Review antwoordde dat de App Review Board had gereageerd. De developer vroeg daarna om de specifieke schermen waar het om ging, en er werd geen oplossing gepost.
• In een Flutter-issue op GitHub kregen meerdere developers bij eenvoudige apps te horen: "We discovered that your app contains hidden features". Een Flutter-contributor noemde het framework "a red herring" (een dwaalspoor) en wees op ongedocumenteerde API's in de app-code of plug-ins. Twee developers meldden goedkeuring na een beroep, zonder hun code te wijzigen.
• Een developer op de Apple Developer Forums werd afgewezen onder 1.2, ondanks een EULA, filtering, een meldfunctie en blokkeren. Er werd gevraagd om voorwaarden met "geen tolerantie voor aanstootgevende content" en om "binnen 24 uur te reageren op meldingen van aanstootgevende content". Een tweede afwijzing voegde daar een leeftijdsclassificatie van 18+, directe verwijdering van posts en contactgegevens in de app aan toe. De developer reageerde door elke waarborg te documenteren en admin-inloggegevens in de review notes te zetten.

Les: in alle drie de gevallen konden reviewers functies niet zien of verifiëren die de developers vanzelfsprekend vonden. Onder 2.5.19 en de strengere 1.2 doen de review notes en het demo-account net zoveel werk als de code. Onze gids voor een demo-account voor App Store-review legt uit hoe je die inricht.

Wat moet je controleren vóór je volgende inzending?

Controleer vóór je volgende build feature flags, UGC-waarborgen, creative assets en externe links aan de hand van de nieuwe tekst, en schrijf daarna review notes die naar elk onderdeel verwijzen. De checklist hieronder dekt de wijzigingen van oktober 2026.

1. Maak een lijst van elke servergestuurde flag, elke remote config-sleutel en elk verborgen menu. Zet ze allemaal aan voor de reviewer, of verwijder de code die ze aansturen.
2. Beschrijf elke nieuwe functie specifiek in Notes for Review, zoals 2.3.1(a) vereist, inclusief hoe de reviewer alles bereikt wat achter uitnodigingen, scans of betaalde niveaus zit.
3. Als gebruikers kunnen posten, chatten of content genereren, controleer dan of filtering, een meldfunctie, blokkeren en gepubliceerde contactgegevens allemaal in de build zitten, en leg je proces voor het afhandelen van meldingen vast.
4. Voeg bij AI-beeld- of videogeneratie filters op prompts en output toe die seksuele beelden van echte personen blokkeren, en geef gebruikers een manier om output te melden.
5. Controleer elke creative asset op prijzen, kortingen, URL's, claims over onderscheidingen, logo's van andere platforms en alles wat boven een 4+-classificatie uitkomt.
6. Gebruik je een entitlement voor een externe aankooplink of muziekstreaming, controleer dan of de link in elke storefront naar een toegestane bestemming gaat.
7. Lees de Engelse richtlijnen opnieuw voor elke sectie waarop je vertrouwt, omdat vertalingen tot een maand achter kunnen lopen.

Uitgewerkt voorbeeld: neem een AI-avatarapp met een openbare galerij en een "Pro"-stijlpakket dat na de lancering via remote config wordt ingeschakeld. Onder de nieuwe tekst heeft die app moderatie en een meldfunctie voor de galerij nodig (1.2). Het Pro-pakket moet zichtbaar zijn in de beoordeelde build of worden uitgesteld tot een latere versie (2.5.19). De header-asset voor iOS 27 mag niet "Pro nu 40% korting" zeggen (2.3.14). Heb je al met een afwijzing te maken, dan legt onze gids per richtlijn voor het oplossen van afwijzingen uit hoe je in App Store Connect reageert. Wil je dat iemand anders meekijkt voordat je indient, bekijk dan onze diensten.