# Guideline 2.3.1: skjulte funktioner og OTA-opdateringer

> Guideline 2.3.1: Apple afviser enhver skjult, sovende eller udokumenteret funktion. Her er, hvad du må ændre på afstand, og hvad der kræver et nyt build.

Original side: [Guideline 2.3.1: skjulte funktioner og OTA-opdateringer](https://devoria.fr/da/blog/guideline-2-3-1-skjulte-funktioner-ota-opdateringer)
Forfatter: [Mehdi Azizi](https://devoria.fr/da/mehdi-azizi)
Udgivet: 2026-11-04
Indhold senest revideret: 2026-11-04


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](https://developer.apple.com/app-store/review/guidelines/#2.3.1), 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](https://devoria.fr/da/blog/guideline-2-3-10-app-afvist-metadata) 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](https://github.com/microsoft/react-native-code-push/issues/2680): "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](https://github.com/microsoft/react-native-code-push/issues/2434), 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](https://developer.apple.com/app-store/review/guidelines/#2.5.2), som jeg også gennemgår i guiden om [baggrundstilstande](https://devoria.fr/da/blog/guideline-2-5-4-baggrundstilstand-afvist-apple), 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](https://developer.apple.com/support/terms/apple-developer-program-license-agreement/#b331) 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](https://docs.expo.dev/eas-update/introduction/) 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](https://developer.apple.com/help/app-store-connect/reference/app-information/platform-version-information). 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](https://developer.apple.com/help/app-store-connect/manage-submissions-to-app-review/submit-an-in-app-purchase). Expo regner native kode, tilladelser og SDK-version blandt det, der kræver en ny binærfil, ligesom ved [ITMS-90683](https://devoria.fr/da/blog/itms-90683-missing-purpose-string-expo). 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](https://devoria.fr/da/blog/guideline-3-1-2-app-afvist-abonnement).

## Demotilstand og testkonti

[Guideline 2.1](https://devoria.fr/da/blog/guideline-2-1-app-store-afvisning) 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`:

```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](https://docs.expo.dev/eas-update/runtime-versions/)). 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](https://docs.expo.dev/versions/latest/sdk/updates/)). 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:

```text
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](https://developer.apple.com/help/app-store-connect/manage-submissions-to-app-review/reply-to-app-review-messages/).

- **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](https://devoria.fr/da/kits/app-review) 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](https://devoria.fr/da/coaching): 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](https://devoria.fr/da/expertise/app-afvist-af-apple).

Forbereder du din første lancering? [Tag din gratis diagnose](https://devoria.fr/da/diagnostic): 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.


## Dit projekt

[Review Kit](https://devoria.fr/da/kits/app-review): Min tjekliste til App Store-review, mine afvisninger fra Apple og hvordan jeg rettede dem, tjeklisten til Google Play og tre Claude Code-skills. 369 kr..

[iOS & Android Kit](https://devoria.fr/da/kits/ios): Byg din iPhone- og Android-app med Claude Code: startkoden fra mine apps, vejen helt ud i butikkerne og alle kits. 739 kr..

[Diagnose: det, der skiller dig fra din iPhone-app](https://devoria.fr/da/diagnostic): 7 spørgsmål, 60 sekunder: du finder ud af, hvad der reelt holder dig tilbage fra at udgive din iPhone-app, får din vej i 4 trin og det kit, der passer til dig.