# Guideline 2.3.1: dolda funktioner och OTA-uppdateringar

> Guideline 2.3.1: Apple avvisar dolda, vilande eller odokumenterade funktioner. Vad du kan ändra på distans och vad som kräver ett nytt build.

Originalsida: [Guideline 2.3.1: dolda funktioner och OTA-uppdateringar](https://devoria.fr/sv/blog/guideline-2-3-1-dolda-funktioner-ota-uppdateringar)
Författare: [Mehdi Azizi](https://devoria.fr/sv/mehdi-azizi)
Publicerad: 2026-11-04
Innehållet senast granskat: 2026-11-04


Guideline 2.3.1 förbjuder dolda, vilande eller odokumenterade funktioner: allt din app gör ska synas för användaren och för granskaren. Varje nyhet beskrivs exakt i granskningsanteckningarna. **En fjärruppdatering kan rätta det Apple har sett, aldrig lägga till det Apple inte har sett.**

Jag publicerar mina iOS-appar med Expo, och alla har EAS Update inbyggt från första buildet för att leverera buggfixar. Min regel: ingen fjärruppdatering medan en version granskas. Den här guiden bygger på Apples text, deras licensavtal, Expos dokumentation och publicerade avslag.

## Vad säger guideline 2.3.1?

2.3.1 inleder del 2.3 "Accurate Metadata" i [App Review Guidelines](https://developer.apple.com/app-store/review/guidelines/#2.3.1), under avsnitt 2 "Performance". Texten börjar så här: "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: inget dolt, vilande eller odokumenterat.

Fortsättningen gäller varje inskickning: "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." **Varje nyhet ska beskrivas exakt i granskningsanteckningarna och vara tillgänglig för granskaren.** "Buggfixar och förbättringar" räcker alltså inte.

Samma stycke riktar sig mot vilseledande marknadsföring: att utlova innehåll eller en tjänst som inte finns, eller visa ett falskt pris, i App Store eller någon annanstans.

Den delen hade jag nytta av för Nolera. När jag läste igenom produktsidan före lanseringen hittade jag två meningar som inte gick att belägga: "gränssnitt endast på franska", som hade blivit fel, och "det mest valda paketet", för en app som aldrig publicerats. Anteckningarna till granskaren beskrev dessutom ett inaktuellt läge i produkten. Det är precis det här som delen tar sikte på. [2.3.10](https://devoria.fr/sv/blog/guideline-2-3-10-app-avvisad-metadata) handlar däremot främst om produktsidan.

## Vad betyder avslagsmeddelandet för 2.3.1?

Avslaget heter "Guideline 2.3.1 - Performance", ibland följt av "Hidden Features". Två meddelanden som React Native-utvecklare har publicerat:

- **Mars 2024**, i ett [GitHub-ärende för CodePush](https://github.com/microsoft/react-native-code-push/issues/2680): "The app contains hidden features.", utan någon ytterligare förklaring. Utvecklaren ber om förtydligande och får ett tillägg med hänvisning till 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." Ärendet säger inte om appen gick igenom efteråt.
- **Februari 2023**, i ett [annat ärende](https://github.com/microsoft/react-native-code-push/issues/2434), pekar Apple på binärens "CodePush-related remote code downloading/updating support".

Min tolkning: **granskaren ser inte dina uppdateringar, den ser koden som kan ta emot dem.** Båda fallen gäller CodePush. Jag har inte hittat något färskt offentligt avslag som gäller EAS Update, vilket inte bevisar något.

## Fjärruppdateringar: vad 2.5.2 och licensavtalet tillåter

[Regel 2.5.2](https://developer.apple.com/app-store/review/guidelines/#2.5.2), som jag också tar upp i guiden om [bakgrundslägen](https://devoria.fr/sv/blog/guideline-2-5-4-bakgrundslage-avvisat-apple), förbjuder appen att "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) förbjuder nedladdad körbar kod, men preciserar: "Interpreted code may be downloaded to an Application". Med tre villkor: koden ändrar inte appens huvudsyfte, den kringgår varken signering, sandlåda eller systemets säkerhetsfunktioner, och den skapar ingen butik för andra appar.

JavaScript i en Expo-app är tolkad kod: enligt mig ryms EAS Update inom den ramen. Dess [dokumentation](https://docs.expo.dev/eas-update/introduction/) påminner om att uppdateringar följer App Stores regler, och att "changes to your app's behavior need to be reviewed". Vid en kritisk bugg föreslår Expo en fix på distans, följt av en ny inskickning som innehåller den.

**Min linje: rätta och justera det som finns, ja. Ändra vad appen är eller vad den säljer, nej.**

## Vad du kan ändra på distans och vad som kräver ett nytt build

Tabellen jag använder, hämtad från Apples och Expos sidor som citeras här. Raden "gratis blir betalt" och de två sista raderna är min tolkning.

| Ändring                      | Väg                      | Varför                         |
| ---------------------------- | ------------------------ | ------------------------------ |
| JavaScript-bugg              | Fjärruppdatering         | Avsedd användning i Expo       |
| Text, översättning, stil     | Fjärruppdatering         | Avsedd användning i Expo       |
| Pris på en prenumeration     | App Store Connect        | Ingen kod ändras               |
| Kampanjtext                  | App Store Connect        | Utan ny inskickning            |
| Köp av en redan godkänd typ  | Granskning av bara köpet | Regel i App Store Connect      |
| Första köpet av en typ       | Ny version               | Regel i App Store Connect      |
| Ny funktion                  | Ny version               | 2.3.1 och 2.5.2                |
| Gratis blir betalt           | Ny version               | Sida och anteckningar ses över |
| Behörighet, Info.plist       | Nytt build               | Fil i binären                  |
| Native-modul, Expo SDK       | Nytt build               | Native-kod ändrad              |
| Brytare som stänger av       | Fjärrkonfiguration       | Tolereras om tillfällig        |
| Brytare som visar något nytt | Förbjudet                | Funktion aldrig granskad       |

Kampanjtexten (promotional text) ändras "without requiring an updated submission", enligt Apples sida om [versionsinformation](https://developer.apple.com/help/app-store-connect/reference/app-information/platform-version-information). Det första köpet av varje typ skickas med en ny version, de följande separat, enligt hjälpsidan om att [skicka in köp](https://developer.apple.com/help/app-store-connect/manage-submissions-to-app-review/submit-an-in-app-purchase). Expo räknar native-kod, behörigheter och SDK-version till det som kräver en ny binär, precis som för [ITMS-90683](https://devoria.fr/sv/blog/itms-90683-missing-purpose-string-expo). En brytare som stänger av en trasig funktion lägger inte till något nytt, så länge den inte tar bort det prenumeranterna har betalat för.

## Fjärrbrytare utan avslag

En fjärrbrytare, eller feature flag, är inte förbjuden i sig: allt hänger på vad den döljer. Mina regler:

- **Allt en brytare kan visa finns med och är påslaget för granskaren**, och namnges i granskningsanteckningarna.
- Ett A/B-test jämför två varianter som granskaren kan se, aldrig en granskad variant och en ny.
- **Ingen kod upptäcker granskningen för att bete sig annorlunda.** Det är själva definitionen av en dold funktion.
- En paywall som styrs på distans visar bara godkända produkter, och varje variant följer [regel 3.1.2](https://devoria.fr/sv/blog/guideline-3-1-2-app-nekad-prenumeration).

## Demoläge och testkonton

[Guideline 2.1](https://devoria.fr/sv/blog/guideline-2-1-app-store-avslag-app-completeness) kräver ett demokonto om din app har inloggning, med servern igång. Om juridiska krav eller säkerhetskrav hindrar dig från att ge ett, kan ett inbyggt demoläge ersätta det, men bara "with prior approval by Apple", och det måste visa alla funktioner. Apples sida om versionsinformation lägger till: kontot får inte gå ut, och extra konton anges i anteckningarna, som är begränsade till 4 000 byte.

Kopplingen till 2.3.1: **ett demoläge eller testkonto som öppnar skärmar som annars är osynliga måste beskrivas.** En hemlig gest, en kod eller ett specialkonto som inte nämns är en dold funktion. Namnge varje specialåtkomst i anteckningarna, tillsammans med vad den öppnar.

## Min regel: ingen fjärruppdatering under en granskning

Varför jag har EAS Update överallt: i Solys, min väckarklocka, gjorde en JavaScript-bugg appen tyst så fort ett ljud misslyckades en enda gång. Fixen var tre rader, men det krävdes ett fullt build och en granskning för att leverera den. Sedan dess har alla mina appar expo-updates från första buildet: det är en native-modul, och en binär som kompilerats utan den kommer aldrig att ta emot något. Min konfiguration, i `app.json`:

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

Med `fingerprint` når en uppdatering bara binärer vars native-kod matchar ([runtime-versioner](https://docs.expo.dev/eas-update/runtime-versions/)). Men medan en version väntar på eller genomgår granskning publicerar jag ingenting. Två skäl.

1. **Granskaren skulle inte se fixen.** Med `fallbackToCacheTimeout` satt till 0 startar en ny installation på den inbyggda koden och tillämpar uppdateringen vid nästa start ([dokumentationen för expo-updates](https://docs.expo.dev/versions/latest/sdk/updates/)). Granskaren installerar, startar en gång och testar binären. Nolera avvisades trots att en fix redan hade levererats på distans: jag berättar om det i guiden om 2.1.
2. **Det granskaren testar ska förbli det användarna får.** Att ändra beteendet under granskningen skapar en skillnad mellan versionen som granskades och versionen som levereras.

## Exakta granskningsanteckningar

2.3.1 avvisar generiska beskrivningar. Mallen jag skulle använda, på engelska:

```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.
```

## Hur svarar man på ett avslag enligt 2.3.1?

Svara i App Store Connect, där du [svarar på meddelandet från App Review](https://developer.apple.com/help/app-store-connect/manage-submissions-to-app-review/reply-to-app-review-messages/).

- **Meddelandet är vagt**: fråga vilken funktion det gäller, som utvecklaren i ärendet från 2024.
- **En verklig funktion är dåligt beskriven**: ange exakt väg dit och en kort video, och komplettera sedan anteckningarna.
- **En brytare visar något ogranskat**: ta bort den, eller slå på den och beskriv den, och gör sedan ett nytt build.
- **Uppdateringskoden ifrågasätts**: förklara att den används för buggfixar, inom ramen för artikel 3.3.1(B). I ärendet från 2023 bad Apple om att den skulle tas bort.

## Checklistan för 2.3.1 före inskickning

- Varje nyhet i versionen är beskriven i anteckningarna, med vägen dit.
- Varje fjärrbrytare är påslagen för granskningen och namngiven i anteckningarna.
- Ingen kod ändrar beteende för granskaren.
- Specialåtkomster är beskrivna: demoläge, testkonto, gest.
- Produktsidan och paywallen lovar inget som buildet inte gör.
- Ingen fjärruppdatering publiceras under granskningen.

## Kontrollera ditt underlag före inskickning

[Review Kit](https://devoria.fr/sv/kits/app-review) samlar min checklista före inskickning, mallar för anteckningar till testaren och Claude Code-skills som går igenom ditt projekt. Vill du ha ett mänskligt öga, [boka en timme med mig](https://devoria.fr/sv/coaching): vi går igenom dina granskningsanteckningar och din uppdateringskonfiguration tillsammans, via videosamtal. Hela tillvägagångssättet finns på sidan [app avvisad av Apple](https://devoria.fr/sv/expertise/app-nekad-av-apple).

Förbereder du din första lansering? [Gör din gratis diagnos](https://devoria.fr/sv/diagnostic): den sätter stegen i rätt ordning och skickar dig min checklista mot avslag från Apple.

## Vanliga frågor

### Vad betyder "Guideline 2.3.1 - Performance - Hidden Features"?

Apple anser att din app innehåller en dold eller vilande funktion, eller en som saknas i granskningsanteckningarna. Meddelandet kan också gälla kod som kan ändra appen efter granskningen, ibland tillsammans med ett avslag enligt 2.5.2.

### Tillåter Apple EAS Update?

Licensavtalet tillåter nedladdad tolkad kod så länge den inte ändrar appens huvudsyfte. Rätta fel, ja. Lägga till en ogranskad funktion, nej.

### Kan man använda feature flags i en iOS-app?

Ja, om allt de kan visa har granskats. Slå på varje brytare för granskningen och beskriv den i anteckningarna.

### Måste man berätta om ett demoläge för granskaren?

Ja. Ett inbyggt demoläge kräver Apples förhandsgodkännande och måste visa alla funktioner.

### Får man publicera en fjärruppdatering under granskningen?

Inget förbjuder det svart på vitt. Men granskaren skulle inte se den vid första starten, och den skapar en skillnad mot den granskade versionen. Jag avstår alltid.


## Ditt projekt

[Review Kit](https://devoria.fr/sv/kits/app-review): Min checklista för App Store-granskningen, mina avslag från Apple och hur jag fixade dem, en för Google Play och tre Claude Code-skills. 549 kr.

[iOS & Android Kit](https://devoria.fr/sv/kits/ios): Bygg din app för iPhone och Android med Claude Code: startkoden från mina appar, hela vägen till butikerna och alla kit. 1 099 kr.

[Diagnos: det som skiljer dig från din iPhone-app](https://devoria.fr/sv/diagnostic): 7 frågor, 60 sekunder: du får veta vad som egentligen hindrar dig från att publicera din iPhone-app, din väg i 4 steg och kitet som passar dig.
