Guideline 2.3.1: skjulte funksjoner og OTA-oppdateringer

Guideline 2.3.1 forbyr skjulte, sovende eller udokumenterte funksjoner: alt appen din gjør, må være synlig for brukeren og for revieweren. Hver nyhet skal beskrives presist i notatene til gjennomgangen. En ekstern oppdatering kan rette det Apple har sett, aldri legge til det Apple ikke har sett.

Jeg publiserer iOS-appene mine med Expo, og hver av dem har EAS Update med fra første build for å levere rettelser. Regelen min: ingen eksterne oppdateringer mens en versjon er til gjennomgang. Denne guiden bygger på Apples tekst, lisensen deres, Expos dokumentasjon og publiserte avvisninger.

Hva sier guideline 2.3.1?

2.3.1 innleder del 2.3 «Accurate Metadata» i App Review Guidelines, under seksjon 2 «Performance». Teksten starter slik: «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: ingenting skjult, sovende eller udokumentert.

Resten gjelder hver innsending: «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 nyhet må beskrives presist i notatene til gjennomgangen, og være tilgjengelig for revieweren. «Feilrettinger og forbedringer» holder altså ikke.

Det samme avsnittet retter seg mot villedende markedsføring: å love innhold eller en tjeneste som ikke finnes, eller vise en falsk pris, i App Store eller andre steder.

Denne delen kom godt med for Nolera. Da jeg leste gjennom produktsiden før lansering, fant jeg to setninger som ikke kunne etterprøves: «grensesnitt kun på fransk», som ikke lenger stemte, og «den mest valgte pakken», for en app som aldri var publisert. Notatene til revieweren beskrev også en utdatert versjon av produktet. Det er akkurat dette denne delen sikter mot. 2.3.10 handler derimot mest om produktsiden.

Hva betyr avvisningsmeldingen 2.3.1?

Avvisningen har tittelen «Guideline 2.3.1 - Performance», noen ganger etterfulgt av «Hidden Features». To meldinger publisert av React Native-utviklere:

• Mars 2024, i en GitHub-sak for CodePush: «The app contains hidden features.», uten flere detaljer. Utvikleren ber om utdypning og får et tillegg 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.» Saken sier ikke om appen ble godkjent etterpå.
• Februar 2023, i en annen sak, peker Apple på binærfilens «CodePush-related remote code downloading/updating support».

Min tolkning: revieweren ser ikke oppdateringene dine, men koden som kan ta imot dem. Begge tilfellene gjelder CodePush. Jeg har ikke funnet noen nylig offentlig avvisning rettet mot EAS Update, men det beviser ingenting.

Eksterne oppdateringer: hva 2.5.2 og lisensen tillater

Regel 2.5.2, som jeg også tar opp i guiden om bakgrunnsmoduser, forbyr appen å «download, install, or execute code which introduces or changes features or functionality of the app».

Punkt 3.3.1(B) i Apple Developer Program License Agreement forbyr nedlastet kjørbar kode, men presiserer: «Interpreted code may be downloaded to an Application». Med tre betingelser: koden endrer ikke appens hovedformål, den omgår verken signering, sandkasse eller systemets sikkerhetsfunksjoner, og den lager ingen butikk for andre apper.

JavaScript i en Expo-app er tolket kode: etter mitt syn faller EAS Update innenfor denne rammen. Dokumentasjonen minner om at oppdateringer følger App Store-reglene, og at «changes to your app's behavior need to be reviewed». For en kritisk feil foreslår Expo en ekstern rettelse, deretter en ny innsending som inneholder den.

Min linje: rette og justere det som finnes, ja. Endre hva appen er eller hva den selger, nei.

Hva du kan endre eksternt, og hva som krever nytt build

Rammeverket jeg bruker, hentet fra Apples og Expos sider som er sitert her. Raden «gratis blir betalt» og de to siste er min tolkning.

Endring	Vei	Hvorfor
JavaScript-feil	Ekstern oppdatering	Bruk Expo har tenkt på
Tekst, oversettelse, stil	Ekstern oppdatering	Bruk Expo har tenkt på
Pris på et abonnement	App Store Connect	Ingen kode endret
Kampanjetekst	App Store Connect	Uten ny innsending
Kjøp av en allerede godkjent type	Gjennomgang av kjøpet alene	Regel i App Store Connect
Første kjøp av en type	Ny versjon	Regel i App Store Connect
Ny funksjon	Ny versjon	2.3.1 og 2.5.2
Gratis blir betalt	Ny versjon	Produktside og notater må oppdateres
Tillatelse, Info.plist	Nytt build	Fil i binærfilen
Native modul, Expo SDK	Nytt build	Native kode endret
Bryter som skrur av	Ekstern konfigurasjon	Tolerert hvis midlertidig
Bryter som avslører	Forbudt	Funksjon aldri gjennomgått

Kampanjeteksten kan endres «without requiring an updated submission», ifølge Apples side om versjonsinformasjon. Det første kjøpet av hver type sendes inn med en ny versjon, de neste alene, ifølge hjelpesiden om innsending av kjøp. Expo regner native kode, tillatelser og SDK-versjon blant det som krever en ny binærfil, som for ITMS-90683. En bryter som skrur av en funksjon som ikke virker, legger ikke til noe nytt, så lenge den ikke fjerner det abonnentene har betalt for.

Eksterne brytere uten avvisning

En ekstern bryter, eller feature flag, er ikke forbudt i seg selv: alt avhenger av hva den skjuler. Reglene mine:

• Alt en bryter kan vise, er til stede og skrudd på for revieweren, og nevnt i notatene til gjennomgangen.
• En A/B-test sammenligner to varianter revieweren kan se, aldri én gjennomgått variant og én ukjent.
• Ingen kode oppdager gjennomgangen for å oppføre seg annerledes. Det er selve definisjonen av en skjult funksjon.
• En paywall som styres eksternt, viser bare godkjente produkter, og hver variant følger regel 3.1.2.

Demomodus og testkontoer

Guideline 2.1 krever en demokonto hvis appen din har innlogging, med serveren oppe. Hvis juridiske eller sikkerhetsmessige forpliktelser hindrer deg i å gi en, kan en innebygd demomodus erstatte den, men bare «with prior approval by Apple», og den må vise alle funksjonene. Apples side om versjonsinformasjon legger til: kontoen utløper ikke, og ekstra kontoer skal i notatene, som er begrenset til 4 000 byte.

Koblingen til 2.3.1: en demomodus eller testkonto som åpner skjermer som ellers er usynlige, må beskrives. En hemmelig bevegelse, en kode eller en spesialkonto som ikke er nevnt, er en skjult funksjon. Nevn hver spesialtilgang i notatene, med hva den åpner.

Min regel: ingen eksterne oppdateringer under en gjennomgang

Hvorfor EAS Update er overalt hos meg: i Solys, vekkerklokkeappen min, gjorde en JavaScript-feil appen stum så snart en lydeffekt feilet én gang. Rettelsen var tre linjer, men det krevde et fullt build og en gjennomgang å levere den. Siden da har alle appene mine expo-updates med fra første build: det er en native modul, så en binærfil kompilert uten den vil aldri motta noe. Konfigurasjonen min, i app.json:

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

Med fingerprint når en oppdatering bare binærfiler med samsvarende native kode (kjøretidsversjoner). Men mens en versjon venter på eller er under gjennomgang, publiserer jeg ingenting. Av to grunner.

1. Revieweren ville ikke sett rettelsen. Med fallbackToCacheTimeout satt til 0 starter en ny installasjon på den innebygde koden og tar i bruk oppdateringen ved neste oppstart (dokumentasjonen til expo-updates). Revieweren installerer, starter én gang og tester binærfilen. Nolera ble avvist med en rettelse som allerede var levert eksternt: jeg forteller om det i guiden om 2.1.
2. Det revieweren tester, må forbli det brukerne får. Å endre oppførselen under gjennomgangen skaper et gap mellom versjonen som ble sett og versjonen som blir levert.

Presise notater til gjennomgangen

2.3.1 avviser generiske beskrivelser. Malen jeg ville brukt, 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 svare på en 2.3.1-avvisning?

Svar i App Store Connect, der du svarer på meldingen fra App Review.

• Meldingen er vag: spør hvilken funksjon det gjelder, slik utvikleren i saken fra 2024 gjorde.
• En ekte funksjon er dårlig beskrevet: oppgi den nøyaktige veien og en kort video, og fyll så ut notatene.
• En bryter avslører noe nytt: fjern den, eller skru den på og beskriv den, og lag så et nytt build.
• Oppdateringskoden er problemet: forklar at den brukes til rettelser, innenfor rammen av punkt 3.3.1(B). I saken fra 2023 ba Apple om at den ble fjernet.

Sjekklisten for 2.3.1 før innsending

• Hver nyhet i versjonen er beskrevet i notatene, med veien dit.
• Hver ekstern bryter er skrudd på for gjennomgangen og nevnt i notatene.
• Ingen kode endrer oppførsel for revieweren.
• Spesialtilganger er beskrevet: demomodus, testkonto, bevegelse.
• Produktsiden og paywallen lover ingenting buildet ikke gjør.
• Ingen ekstern oppdatering publiseres under gjennomgangen.

Sjekk innsendingen din før du sender

Review Kit samler sjekklisten min før innsending, maler for notater til testeren og Claude Code-skills som går gjennom prosjektet ditt. Vil du ha et menneskelig blikk, book en time med meg: vi går gjennom notatene og oppdateringskonfigurasjonen din sammen, på video. Hele fremgangsmåten finner du på siden om app avvist av Apple.

Forbereder du din første lansering? Ta den gratis diagnosen: den setter stegene i riktig rekkefølge og sender deg sjekklisten min mot avvisning fra Apple.

Ofte stilte spørsmål

Hva betyr «Guideline 2.3.1 - Performance - Hidden Features»?

Apple mener appen din inneholder en skjult eller sovende funksjon, eller en som mangler i notatene til gjennomgangen. Meldingen kan også gjelde kode som kan endre appen etter gjennomgangen, noen ganger sammen med en 2.5.2-avvisning.

Tillater Apple EAS Update?

Lisensen tillater nedlastet tolket kode så lenge den ikke endrer appens hovedformål. Rette feil, ja. Legge til en funksjon som ikke er gjennomgått, nei.

Kan man bruke feature flags i en iOS-app?

Ja, hvis alt de kan vise, er gjennomgått. Skru på hver bryter for gjennomgangen og beskriv den i notatene.

Må man fortelle revieweren om en demomodus?

Ja. En innebygd demomodus krever forhåndsgodkjenning fra Apple og må vise alle funksjonene.

Kan man publisere en ekstern oppdatering under gjennomgangen?

Ingenting forbyr det svart på hvitt. Men revieweren ville ikke sett den ved første oppstart, og den skaper et gap mot den gjennomgåtte versjonen. Jeg lar alltid være.