Guideline 2.3.1: verborgen functies en OTA-updates

Guideline 2.3.1 verbiedt verborgen, slapende of niet-gedocumenteerde functies: alles wat je app doet, moet zichtbaar zijn voor de gebruiker en voor de reviewer. Elke nieuwe functie beschrijf je precies in de review-notes. Een update op afstand mag corrigeren wat Apple heeft gezien, nooit toevoegen wat Apple niet heeft gezien.

Ik publiceer mijn iOS-apps met Expo, en elke app heeft EAS Update vanaf de eerste build aan boord om fixes te leveren. Mijn regel: geen enkele update op afstand zolang een versie in review is. Deze gids baseert zich op de tekst van Apple, de licentie, de documentatie van Expo en gepubliceerde afwijzingen.

Wat zegt guideline 2.3.1?

De 2.3.1 opent deel 2.3 "Accurate Metadata" van de App Review Guidelines, in sectie 2 "Performance". De tekst begint zo: "Don't include any hidden, dormant, or undocumented features in your app; your app's functionality should be clear to end users and App Review." Kortom: niets verborgen, slapend of ongedocumenteerd.

Het vervolg geldt voor elke inzending: "All new features, functionality, and product changes must be described with specificity in the Notes for Review section of App Store Connect (generic descriptions will be rejected) and accessible for review." Elke nieuwe functie moet precies beschreven staan in de review-notes, en bereikbaar zijn voor de reviewer. "Bugfixes en verbeteringen" is dus niet genoeg.

Dezelfde alinea richt zich op misleidende marketing: content of een dienst beloven die er niet is, of een nepprijs tonen, in de App Store of elders.

Dat deel heeft me geholpen bij Nolera. Toen ik de productpagina voor de lancering nog eens las, vond ik twee onverifieerbare zinnen: "interface alleen in het Frans", inmiddels onjuist, en "het meest gekozen pakket", voor een app die nog nooit gepubliceerd was. De notes voor de reviewer beschreven ook een verouderde staat van het product. Precies waar dit deel op mikt. De 2.3.10 richt zich vooral op de productpagina.

Wat betekent de afwijzing 2.3.1?

De afwijzing heet "Guideline 2.3.1 - Performance", soms gevolgd door "Hidden Features". Twee berichten die React Native-ontwikkelaars publiceerden:

• Maart 2024, in een GitHub-issue van CodePush: "The app contains hidden features.", zonder verdere uitleg. De ontwikkelaar vraagt om verduidelijking en krijgt een aanvulling op grond van 2.5.2: "Your app, extension, or linked framework appears to contain code designed explicitly with the capability to change the app's behavior or functionality after App Review approval." Het issue zegt niet of de app daarna is goedgekeurd.
• Februari 2023, in een ander issue, richt Apple zich op de "CodePush-related remote code downloading/updating support" in de binary.

Mijn lezing: de reviewer ziet je updates niet, hij ziet de code die ze kan ontvangen. Beide gevallen gaan over CodePush. Ik heb geen recente openbare afwijzing gevonden die EAS Update betreft, maar dat bewijst niets.

Updates op afstand: wat 2.5.2 en de licentie toestaan

Regel 2.5.2, die ik ook behandel in de gids over achtergrondmodi, verbiedt de app om "download, install, or execute code which introduces or changes features or functionality of the app".

Artikel 3.3.1(B) van de Apple Developer Program License Agreement verbiedt gedownloade uitvoerbare code, maar zegt: "Interpreted code may be downloaded to an Application". Onder drie voorwaarden: die code verandert het hoofddoel van de app niet, omzeilt de ondertekening, de sandbox en de beveiliging van het systeem niet, en maakt geen winkel voor andere apps.

Het JavaScript van een Expo-app is geïnterpreteerde code: volgens mij valt EAS Update binnen dat kader. De documentatie herinnert eraan dat updates de regels van de App Store volgen, en dat "changes to your app's behavior need to be reviewed". Voor een kritieke bug stelt Expo de fix op afstand voor, en daarna een nieuwe inzending waarin die fix zit.

Mijn lijn: corrigeren en bijstellen wat er al is, ja. Veranderen wat de app is of wat ze verkoopt, nee.

Wat je op afstand mag wijzigen en wat een nieuwe build vraagt

Het schema dat ik hanteer, gebaseerd op de pagina's van Apple en Expo die hier geciteerd worden. De regel "gratis wordt betaald" en de laatste twee zijn mijn interpretatie.

Wijziging	Route	Waarom
JavaScript-bug	Update op afstand	Bedoeld gebruik volgens Expo
Tekst, vertaling, stijl	Update op afstand	Bedoeld gebruik volgens Expo
Prijs van een abonnement	App Store Connect	Geen code gewijzigd
Promotietekst	App Store Connect	Zonder nieuwe inzending
Aankoop van al goedgekeurd type	Review van alleen de aankoop	Regel van App Store Connect
Eerste aankoop van een type	Nieuwe versie	Regel van App Store Connect
Nieuwe functie	Nieuwe versie	2.3.1 en 2.5.2
Gratis wordt betaald	Nieuwe versie	Productpagina en notes herzien
Permissie, Info.plist	Nieuwe build	Bestand in de binary
Native module, Expo SDK	Nieuwe build	Native code gewijzigd
Schakelaar die uitzet	Configuratie op afstand	Toegestaan als tijdelijk
Schakelaar die onthult	Verboden	Functie nooit gereviewd

De promotietekst wijzig je "without requiring an updated submission", volgens Apples pagina over versie-informatie. De eerste aankoop van elk type gaat mee met een nieuwe versie, de volgende los, volgens de hulppagina over het indienen van aankopen. Expo rekent native code, permissies en de SDK-versie tot wat een nieuwe binary vraagt, net als bij ITMS-90683. Een schakelaar die een kapotte functie uitzet, voegt niets nieuws toe, zolang hij niet weghaalt waar abonnees voor betaald hebben.

Schakelaars op afstand zonder afwijzing

Een schakelaar op afstand, of feature flag, is op zich niet verboden: alles hangt af van wat hij verbergt. Mijn regels:

• Alles wat een schakelaar kan tonen, is aanwezig en aangezet voor de reviewer, en genoemd in de review-notes.
• Een A/B-test vergelijkt twee varianten die de reviewer kan zien, nooit een gereviewde en een ongeziene variant.
• Geen enkele code detecteert de review om zich anders te gedragen. Dat is letterlijk de definitie van een verborgen functie.
• Een paywall die op afstand wordt aangestuurd, toont alleen goedgekeurde producten, en elke variant respecteert regel 3.1.2.

Demomodus en testaccounts

Guideline 2.1 vraagt een demo-account als je app een login heeft, met de server aan. Als wettelijke of beveiligingsverplichtingen je beletten er een te geven, kan een ingebouwde demomodus het vervangen, maar alleen "with prior approval by Apple", en die moet alle functies tonen. Apples pagina over versie-informatie voegt toe: het account verloopt niet, en extra accounts gaan in de notes, die beperkt zijn tot 4.000 bytes.

Het verband met 2.3.1: een demomodus of testaccount dat schermen opent die anders onzichtbaar zijn, moet beschreven worden. Een geheim gebaar, een code of een speciaal account dat je niet meldt, is een verborgen functie. Noem elke speciale toegang in de notes, met wat die opent.

Mijn regel: geen update op afstand tijdens een review

Waarom EAS Update overal bij mij zit: bij Solys, mijn wekker, maakte een JavaScript-bug de app stil zodra een geluidje één keer mislukte. De fix was drie regels, maar er was een volledige build en een review nodig om hem te leveren. Sindsdien hebben al mijn apps expo-updates vanaf de eerste build: het is een native module, en een binary die zonder gecompileerd is, ontvangt nooit iets. Mijn configuratie, in app.json:

{
  "expo": {
    "runtimeVersion": { "policy": "fingerprint" },
    "updates": { "fallbackToCacheTimeout": 0, "checkAutomatically": "ON_LOAD" }
  }
}

Met fingerprint bereikt een update alleen binaries waarvan de native code overeenkomt (runtimeversies). Maar zolang een versie wacht op of in review is, publiceer ik niets. Twee redenen.

1. De reviewer zou de fix niet zien. Met fallbackToCacheTimeout op 0 start een nieuwe installatie op de meegeleverde code en past de update toe bij de volgende start (documentatie van expo-updates). De reviewer installeert, start één keer en test de binary. Nolera werd afgewezen terwijl er al een fix op afstand was uitgerold: dat vertel ik in de gids over 2.1.
2. Wat de reviewer test, moet blijven wat gebruikers krijgen. Het gedrag tijdens de review veranderen schept een verschil tussen de geziene en de geleverde versie.

Precieze review-notes

2.3.1 weigert generieke beschrijvingen. Het sjabloon dat ik zou gebruiken, in het Engels:

What's new in this version:
- [Feature]: [where to find it, how to test it].

Remote configuration:
- "[flag]" controls [feature]. It is ON for review.

Over-the-air updates:
- The app uses expo-updates for bug fixes only.
  No update will be published during this review.

Demo account: see Sign-in information. It never expires.

Hoe reageer je op een afwijzing 2.3.1?

Reageer in App Store Connect, waar je antwoordt op het bericht van App Review.

• Het bericht blijft vaag: vraag welke functie bedoeld wordt, zoals de ontwikkelaar uit het issue van 2024.
• Een echte functie is slecht beschreven: geef het exacte pad en een korte video, en vul daarna de notes aan.
• Een schakelaar onthult iets nieuws: haal hem weg, of zet hem aan en beschrijf hem, en maak dan een nieuwe build.
• De updatecode is het probleem: leg uit dat die voor fixes dient, binnen het kader van artikel 3.3.1(B). In het issue van 2023 vroeg Apple om hem te verwijderen.

De checklist 2.3.1 voor je inzending

• Elke nieuwe functie van de versie staat beschreven in de notes, met het pad ernaartoe.
• Elke schakelaar op afstand staat aan voor de review en is genoemd in de notes.
• Geen enkele code verandert van gedrag voor de reviewer.
• Speciale toegangen zijn beschreven: demomodus, testaccount, gebaar.
• De productpagina en de paywall beloven niets wat de build niet doet.
• Er wordt geen update op afstand gepubliceerd tijdens de review.

Je dossier controleren voor het versturen

De Review Kit bundelt mijn checklist voor het versturen, sjablonen voor de notes aan de tester en Claude Code-skills die je project nalezen. Wil je een menselijke blik, boek een uur met mij: we lezen samen je review-notes en je updateconfiguratie na, via videocall. De volledige aanpak staat op de pagina app afgewezen door Apple.

Bereid je je eerste release voor? Doe je gratis diagnose: die zet de stappen op volgorde en stuurt je mijn checklist tegen afwijzingen door Apple.

Veelgestelde vragen

Wat betekent "Guideline 2.3.1 - Performance - Hidden Features"?

Apple vindt dat je app een verborgen, slapende of niet in de review-notes beschreven functie bevat. Het bericht kan ook gaan over code die de app na de review kan veranderen, soms samen met een afwijzing 2.5.2.

Staat Apple EAS Update toe?

De licentie staat gedownloade geïnterpreteerde code toe zolang die het hoofddoel van de app niet verandert. Corrigeren, ja. Een niet-gereviewde functie toevoegen, nee.

Mag je feature flags gebruiken in een iOS-app?

Ja, als alles wat ze kunnen tonen gereviewd is. Zet elke schakelaar aan voor de review en beschrijf hem in de notes.

Moet je een demomodus melden aan de reviewer?

Ja. Een ingebouwde demomodus vraagt voorafgaande toestemming van Apple en moet alle functies tonen.

Mag je een update op afstand publiceren tijdens de review?

Nergens staat het zwart op wit verboden. Maar de reviewer zou hem bij de eerste start niet zien, en hij schept een verschil met de gereviewde versie. Ik doe het nooit.