Guideline 2.3.1: skjulte funktioner og OTA-opdateringer

Guideline 2.3.1 forbyder skjulte, sovende eller udokumenterede funktioner: alt, hvad din app gør, skal være synligt for brugeren og for revieweren. Hver nyhed skal beskrives præcist i noterne til review. En opdatering på afstand kan rette det, Apple har set, men aldrig tilføje noget, Apple ikke har set.

Jeg udgiver mine iOS-apps med Expo, og hver eneste har EAS Update med fra første build, så jeg kan levere rettelser. Min regel: ingen opdateringer på afstand, mens en version er i review. Guiden bygger på Apples tekst, Apples licensaftale, Expos dokumentation og offentliggjorte afvisninger.

Hvad siger guideline 2.3.1?

2.3.1 indleder afsnit 2.3 "Accurate Metadata" i App Review Guidelines, under sektion 2 "Performance". Teksten begynder sådan: "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." Kort sagt: intet skjult, intet sovende, intet udokumenteret.

Resten gælder hver indsendelse: "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." Hver nyhed skal beskrives præcist i noterne til review og være tilgængelig for revieweren. "Fejlrettelser og forbedringer" er altså ikke nok.

Samme afsnit rammer også vildledende markedsføring: at love indhold eller en tjeneste, der ikke findes, eller at vise en falsk pris, i App Store eller andre steder.

Den del har jeg haft brug for på Nolera. Da jeg læste app-siden igennem før lanceringen, fandt jeg to sætninger, der ikke kunne dokumenteres: "kun fransk brugerflade", som ikke længere var sand, og "den mest valgte pakke" for en app, der aldrig var udgivet. Noterne til revieweren beskrev også en forældet udgave af produktet. Det er præcis det, den del handler om. 2.3.10 handler derimod mest om selve app-siden.

Hvad betyder afvisningsbeskeden for 2.3.1?

Afvisningen hedder "Guideline 2.3.1 - Performance", nogle gange efterfulgt af "Hidden Features". To beskeder offentliggjort af React Native-udviklere:

• Marts 2024, i en GitHub-issue om CodePush: "The app contains hidden features.", uden yderligere forklaring. Udvikleren beder om en uddybning og får et tillæg under 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." Issuen siger ikke, om appen kom igennem bagefter.
• Februar 2023, i en anden issue, peger Apple på binærfilens "CodePush-related remote code downloading/updating support".

Min læsning: revieweren ser ikke dine opdateringer, men den kode, der kan modtage dem. Begge sager handler om CodePush. Jeg har ikke fundet nogen nylig offentlig afvisning rettet mod EAS Update, men det beviser ingenting.

Opdateringer på afstand: hvad 2.5.2 og licensen tillader

Regel 2.5.2, som jeg også gennemgår i guiden om baggrundstilstande, forbyder appen at "download, install, or execute code which introduces or changes features or functionality of the app".

Artikel 3.3.1(B) i Apple Developer Program License Agreement forbyder downloadet eksekverbar kode, men præciserer: "Interpreted code may be downloaded to an Application". Det kræver tre ting: koden ændrer ikke appens hovedformål, den omgår hverken signering, sandkassen eller systemets sikkerhed, og den skaber ikke en butik for andre apps.

JavaScript i en Expo-app er fortolket kode, så efter min mening falder EAS Update inden for den ramme. Dens dokumentation minder om, at opdateringer skal følge App Stores regler, og at "changes to your app's behavior need to be reviewed". Ved en kritisk fejl anbefaler Expo en rettelse på afstand og derefter en ny indsendelse, der indeholder den.

Min linje: rette og justere det, der findes, ja. Ændre hvad appen er, eller hvad den sælger, nej.

Hvad du kan ændre på afstand, og hvad der kræver et nyt build

Her er det skema, jeg bruger, baseret på de sider fra Apple og Expo, jeg henviser til. Rækken "gratis bliver betalt" og de to sidste rækker er min egen fortolkning.

Ændring	Vej	Hvorfor
JavaScript-fejl	Opdatering på afstand	Brug forudset af Expo
Tekst, oversættelse, stil	Opdatering på afstand	Brug forudset af Expo
Pris på et abonnement	App Store Connect	Ingen kode ændret
Promotional text	App Store Connect	Uden ny indsendelse
Køb af en allerede godkendt type	Review af kun købet	Regel i App Store Connect
Første køb af en type	Ny version	Regel i App Store Connect
Ny funktion	Ny version	2.3.1 og 2.5.2
Gratis bliver betalt	Ny version	App-side og noter skal ses igennem
Tilladelse, Info.plist	Nyt build	Fil i binærfilen
Native modul, Expo SDK	Nyt build	Native kode ændret
Kontakt, der slår fra	Fjernkonfiguration	Accepteret, hvis midlertidig
Kontakt, der afslører	Forbudt	Funktion aldrig reviewet

Promotional text kan ændres "without requiring an updated submission", ifølge Apples side om versionsoplysninger. Det første køb af hver type sendes med en ny version, de næste alene, ifølge hjælpen om indsendelse af køb. Expo regner native kode, tilladelser og SDK-version blandt det, der kræver en ny binærfil, ligesom ved ITMS-90683. En kontakt, der slår en defekt funktion fra, tilføjer ikke noget nyt, så længe den ikke fjerner noget, abonnenterne har betalt for.

Kontakter på afstand uden afvisning

En kontakt på afstand, eller feature flag, er ikke forbudt i sig selv: det afhænger af, hvad den skjuler. Mine regler:

• Alt, hvad en kontakt kan vise, er til stede og slået til for revieweren, og nævnt i noterne til review.
• En A/B-test sammenligner to varianter, som revieweren kan se, aldrig en reviewet variant og en ny.
• Ingen kode registrerer, at appen er i review, for at opføre sig anderledes. Det er selve definitionen på en skjult funktion.
• En paywall, der styres på afstand, viser kun godkendte produkter, og hver variant overholder regel 3.1.2.

Demotilstand og testkonti

Guideline 2.1 kræver en demokonto, hvis din app har login, og serveren skal være tændt. Hvis juridiske eller sikkerhedsmæssige krav forhindrer dig i at levere en, kan en indbygget demotilstand erstatte den, men kun "with prior approval by Apple", og den skal vise alle funktioner. Apples side om versionsoplysninger tilføjer: kontoen må ikke udløbe, og ekstra konti skrives i noterne, som er begrænset til 4.000 bytes.

Forbindelsen til 2.3.1: en demotilstand eller testkonto, der åbner skærme, som ellers er usynlige, skal beskrives. En hemmelig gestus, en kode eller en særlig konto, der ikke er nævnt, er en skjult funktion. Nævn hver særlig adgang i noterne, og hvad den åbner.

Min regel: ingen opdateringer på afstand under et review

Hvorfor EAS Update er overalt hos mig: i Solys, min vækkeur-app, gjorde en JavaScript-fejl appen lydløs, så snart en lydeffekt fejlede én gang. Rettelsen var tre linjer, men det krævede et komplet build og et review at levere den. Siden da har alle mine apps expo-updates med fra første build: det er et native modul, så en binærfil bygget uden det vil aldrig modtage noget. Min konfiguration i app.json:

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

Med fingerprint når en opdatering kun de binærfiler, hvis native kode passer (runtime-versioner). Men mens en version venter på eller er i review, udgiver jeg ingenting. Af to grunde.

1. Revieweren ville ikke se rettelsen. Med fallbackToCacheTimeout sat til 0 starter en ny installation på den indbyggede kode og anvender opdateringen ved næste opstart (expo-updates-dokumentationen). Revieweren installerer, starter én gang og tester binærfilen. Nolera blev afvist med en rettelse, der allerede var leveret på afstand: det fortæller jeg om i guiden til 2.1.
2. Det, revieweren tester, skal være det, brugerne får. At ændre adfærden under review skaber en forskel mellem den version, der blev set, og den, der bliver leveret.

Præcise noter til review

2.3.1 afviser generiske beskrivelser. Den skabelon, jeg ville bruge, på engelsk:

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.

Hvordan svarer du på en 2.3.1-afvisning?

Svar i App Store Connect, hvor du svarer på beskeden fra App Review.

• Beskeden er stadig vag: spørg, hvilken funktion der menes, ligesom udvikleren i issuen fra 2024.
• En reel funktion er dårligt beskrevet: angiv den præcise vej og en kort video, og udbyg så noterne.
• En kontakt afslører noget nyt: fjern den, eller slå den til og beskriv den, og lav så et nyt build.
• Opdateringskoden er problemet: forklar, at den bruges til rettelser inden for rammerne af artikel 3.3.1(B). I issuen fra 2023 bad Apple om, at den blev fjernet.

Tjeklisten til 2.3.1 før indsendelse

• Hver nyhed i versionen er beskrevet i noterne med sin vej.
• Hver kontakt på afstand er slået til under review og nævnt i noterne.
• Ingen kode ændrer adfærd for revieweren.
• Særlige adgange er beskrevet: demotilstand, testkonto, gestus.
• App-siden og paywallen lover intet, som buildet ikke gør.
• Ingen opdatering på afstand udgives under review.

Tjek din indsendelse før afsendelse

Review Kit samler min tjekliste før afsendelse, skabeloner til noter til testeren og Claude Code-skills, der gennemgår dit projekt. Vil du have et menneskeligt blik, så book en time med mig: vi gennemgår dine noter til review og din opdateringskonfiguration sammen over video. Hele fremgangsmåden står på siden om app afvist af Apple.

Forbereder du din første lancering? Tag din gratis diagnose: den sætter trinene i den rigtige rækkefølge og sender dig min tjekliste mod afvisninger fra Apple.

Ofte stillede spørgsmål

Hvad betyder "Guideline 2.3.1 - Performance - Hidden Features"?

Apple mener, at din app indeholder en skjult eller sovende funktion, eller en funktion, der mangler i noterne til review. Beskeden kan også gå på kode, der kan ændre appen efter review, nogle gange sammen med en 2.5.2-afvisning.

Tillader Apple EAS Update?

Licensen tillader downloadet fortolket kode, så længe den ikke ændrer appens hovedformål. At rette, ja. At tilføje en funktion, der ikke er reviewet, nej.

Kan man bruge feature flags i en iOS-app?

Ja, hvis alt, hvad de kan vise, er blevet reviewet. Slå hver kontakt til under review, og beskriv den i noterne.

Skal man fortælle revieweren om en demotilstand?

Ja. En indbygget demotilstand kræver Apples forudgående godkendelse og skal vise alle funktioner.

Må man udgive en opdatering på afstand under review?

Intet forbyder det direkte. Men revieweren ville ikke se den ved første opstart, og den skaber en forskel til den reviewede version. Jeg afholder mig altid fra det.