Guideline 2.3.1: versteckte Funktionen und OTA-Updates

Die Guideline 2.3.1 verbietet versteckte, ruhende oder undokumentierte Funktionen: Alles, was deine App tut, muss für Nutzer und Reviewer sichtbar sein. Jede Neuerung wird in den Review-Notizen genau beschrieben. Ein Remote-Update darf korrigieren, was Apple gesehen hat, aber nie hinzufügen, was Apple nicht gesehen hat.

Ich veröffentliche meine iOS-Apps mit Expo, und jede hat ab ihrem ersten Build EAS Update an Bord, um Fixes auszuliefern. Meine Regel: kein Remote-Update, solange eine Version im Review ist. Dieser Guide stützt sich auf Apples Text, die Lizenzvereinbarung, die Expo-Dokumentation und veröffentlichte Ablehnungen.

Was sagt die Guideline 2.3.1?

Die 2.3.1 eröffnet den Teil 2.3 „Accurate Metadata“ der App Review Guidelines, im Abschnitt 2 „Performance“. Der Text beginnt so: „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.“ Im Klartext: nichts Verstecktes, nichts Schlafendes, nichts Undokumentiertes.

Der nächste Satz betrifft jede Einreichung: „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.“ Jede Neuerung muss in den Review-Notizen genau beschrieben und für den Reviewer zugänglich sein. „Fehlerbehebungen und Verbesserungen“ reicht also nicht.

Derselbe Absatz zielt auf irreführendes Marketing: Inhalte oder Dienste versprechen, die es nicht gibt, oder einen falschen Preis anzeigen, im App Store oder anderswo.

Dieser Teil hat mir bei Nolera geholfen. Beim Durchlesen der Produktseite vor dem Release habe ich zwei unüberprüfbare Sätze gefunden: „Oberfläche nur auf Französisch“, was inzwischen falsch war, und „das meistgewählte Paket“, für eine App, die nie veröffentlicht worden war. Auch die Notizen für den Reviewer beschrieben einen veralteten Stand des Produkts. Genau darauf zielt dieser Teil. Die 2.3.10 dagegen betrifft vor allem die Produktseite.

Was bedeutet die Ablehnungsnachricht 2.3.1?

Die Ablehnung heißt „Guideline 2.3.1 - Performance“, manchmal gefolgt von „Hidden Features“. Zwei Nachrichten, die React-Native-Entwickler veröffentlicht haben:

• März 2024, in einem GitHub-Issue zu CodePush: „The app contains hidden features.“, ohne weitere Details. Der Entwickler fragt nach und bekommt eine Ergänzung unter der 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.“ Das Issue verrät nicht, ob die App danach durchkam.
• Februar 2023, in einem anderen Issue, beanstandet Apple den „CodePush-related remote code downloading/updating support“ im Binary.

Meine Lesart: Der Reviewer sieht nicht deine Updates, er sieht den Code, der welche empfangen kann. Beide Fälle betreffen CodePush. Eine aktuelle öffentliche Ablehnung wegen EAS Update habe ich nicht gefunden, was aber nichts beweist.

Remote-Updates: was 2.5.2 und die Lizenz erlauben

Die Regel 2.5.2, die ich auch im Guide zu den Hintergrundmodi behandle, verbietet der App, „download, install, or execute code which introduces or changes features or functionality of the app“.

Artikel 3.3.1(B) des Apple Developer Program License Agreement verbietet heruntergeladenen ausführbaren Code, präzisiert aber: „Interpreted code may be downloaded to an Application“. Unter drei Bedingungen: Der Code ändert nicht den Hauptzweck der App, er umgeht weder Signatur noch Sandbox noch Sicherheitsmechanismen des Systems, und er schafft keinen Store für andere Apps.

Das JavaScript einer Expo-App ist interpretierter Code: Meiner Ansicht nach fällt EAS Update in diesen Rahmen. Die Dokumentation erinnert daran, dass Updates den App-Store-Regeln folgen und dass „changes to your app's behavior need to be reviewed“. Bei einem kritischen Bug empfiehlt Expo den Remote-Fix und danach eine neue Einreichung, die ihn enthält.

Meine Linie: Bestehendes korrigieren und anpassen, ja. Ändern, was die App ist oder was sie verkauft, nein.

Was du remote ändern kannst und was einen neuen Build braucht

Das Raster, das ich anwende, abgeleitet aus den hier zitierten Seiten von Apple und Expo. Die Zeile „Kostenlos wird kostenpflichtig“ und die letzten beiden Zeilen sind meine Lesart.

Änderung	Weg	Warum
JavaScript-Bug	Remote-Update	Von Expo vorgesehen
Text, Übersetzung, Styling	Remote-Update	Von Expo vorgesehen
Abo-Preis	App Store Connect	Kein Code geändert
Werbetext	App Store Connect	Ohne neue Einreichung
Kauf eines bereits geprüften Typs	Review nur des Kaufs	Regel von App Store Connect
Erster Kauf eines Typs	Neue Version	Regel von App Store Connect
Neue Funktion	Neue Version	2.3.1 und 2.5.2
Kostenlos wird kostenpflichtig	Neue Version	Produktseite und Notizen anpassen
Berechtigung, Info.plist	Neuer Build	Datei im Binary
Natives Modul, Expo SDK	Neuer Build	Nativer Code geändert
Schalter, der abschaltet	Remote-Konfiguration	Toleriert, wenn vorübergehend
Schalter, der freischaltet	Verboten	Funktion nie geprüft

Der Werbetext lässt sich „without requiring an updated submission“ ändern, laut Apples Seite zu den Versionsinformationen. Der erste Kauf jedes Typs geht mit einer neuen Version raus, die weiteren allein, laut der Hilfe zum Einreichen von Käufen. Expo zählt nativen Code, Berechtigungen und SDK-Version zu dem, was ein neues Binary braucht, wie bei ITMS-90683. Ein Schalter, der eine kaputte Funktion abschaltet, fügt nichts Neues hinzu, solange er nicht wegnimmt, wofür Abonnenten bezahlt haben.

Remote-Schalter ohne Ablehnung

Ein Remote-Schalter, also ein Feature Flag, ist an sich nicht verboten: Es hängt alles davon ab, was er versteckt. Meine Regeln:

• Alles, was ein Schalter anzeigen kann, ist für den Reviewer vorhanden und eingeschaltet und in den Review-Notizen benannt.
• Ein A/B-Test vergleicht zwei Varianten, die der Reviewer sehen kann, nie eine geprüfte mit einer ungeprüften.
• Kein Code erkennt das Review, um sich anders zu verhalten. Das ist die Definition einer versteckten Funktion.
• Eine remote gesteuerte Paywall zeigt nur geprüfte Produkte, und jede Variante hält die Regel 3.1.2 ein.

Demo-Modus und Testkonten

Die Guideline 2.1 verlangt ein Demo-Konto, wenn deine App einen Login hat, mit laufendem Server. Wenn rechtliche oder sicherheitsbezogene Pflichten dich daran hindern, eins bereitzustellen, kann ein eingebauter Demo-Modus es ersetzen, aber nur „with prior approval by Apple“, und er muss alle Funktionen zeigen. Apples Seite zu den Versionsinformationen ergänzt: Das Konto läuft nicht ab, und zusätzliche Konten kommen in die Notizen, die auf 4.000 Byte begrenzt sind.

Der Bezug zur 2.3.1: Ein Demo-Modus oder Testkonto, das sonst unsichtbare Screens öffnet, muss beschrieben werden. Eine geheime Geste, ein Code oder ein Spezialkonto ohne Hinweis ist eine versteckte Funktion. Nenne jeden Sonderzugang in den Notizen, mit dem, was er öffnet.

Meine Regel: kein Remote-Update während eines Reviews

Warum EAS Update bei mir überall drin ist: Bei Solys, meinem Wecker, machte ein JavaScript-Bug die App stumm, sobald ein Sound einmal nicht abgespielt wurde. Der Fix war drei Zeilen lang, aber um ihn auszuliefern, brauchte es einen kompletten Build und ein Review. Seitdem haben alle meine Apps expo-updates ab dem ersten Build an Bord: Es ist ein natives Modul, ein ohne es kompiliertes Binary wird nie etwas empfangen. Meine Konfiguration, in app.json:

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

Mit fingerprint erreicht ein Update nur Binaries, deren nativer Code passt (Runtime-Versionen). Aber solange eine Version auf das Review wartet oder im Review ist, veröffentliche ich nichts. Aus zwei Gründen.

1. Der Reviewer würde den Fix nicht sehen. Mit fallbackToCacheTimeout auf 0 startet eine frische Installation mit dem eingebetteten Code und wendet das Update beim nächsten Start an (Dokumentation von expo-updates). Der Reviewer installiert, startet einmal und testet das Binary. Nolera wurde abgelehnt, obwohl der Fix schon remote ausgeliefert war: Das erzähle ich im Guide zur 2.1.
2. Was der Reviewer testet, muss das bleiben, was die Nutzer bekommen. Das Verhalten während des Reviews zu ändern, schafft eine Lücke zwischen geprüfter und ausgelieferter Version.

Präzise Review-Notizen

Die 2.3.1 lehnt generische Beschreibungen ab. Die Vorlage, die ich verwenden würde, auf Englisch:

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.

Wie antwortest du auf eine Ablehnung nach 2.3.1?

Antworte in App Store Connect, wo du auf die Nachricht von App Review antwortest.

• Die Nachricht bleibt vage: Frag, welche Funktion gemeint ist, wie der Entwickler im Issue von 2024.
• Eine echte Funktion ist schlecht beschrieben: Gib den genauen Pfad und ein kurzes Video an und ergänze dann die Notizen.
• Ein Schalter schaltet Ungeprüftes frei: Entferne ihn, oder schalte ihn ein und beschreibe ihn, und mach dann einen neuen Build.
• Der Update-Code ist das Problem: Erkläre, dass er für Fixes dient, im Rahmen von Artikel 3.3.1(B). Im Issue von 2023 verlangte Apple, ihn zu entfernen.

Die 2.3.1-Checkliste vor dem Einreichen

• Jede Neuerung der Version ist in den Notizen beschrieben, mit ihrem Pfad.
• Jeder Remote-Schalter ist für das Review eingeschaltet und in den Notizen benannt.
• Kein Code ändert sein Verhalten für den Reviewer.
• Sonderzugänge sind beschrieben: Demo-Modus, Testkonto, Geste.
• Produktseite und Paywall versprechen nichts, was der Build nicht kann.
• Während des Reviews wird kein Remote-Update veröffentlicht.

Deine Unterlagen vor dem Einreichen prüfen

Das Review Kit bündelt meine Checkliste vor dem Einreichen, Vorlagen für die Notizen an den Tester und Claude-Code-Skills, die dein Projekt durchgehen. Für einen menschlichen Blick buch eine Stunde mit mir: Wir gehen deine Review-Notizen und deine Update-Konfiguration gemeinsam per Videocall durch. Das komplette Vorgehen findest du auf der Seite App von Apple abgelehnt.

Du bereitest deinen ersten Release vor? Mach deine kostenlose Diagnose: Sie bringt die Schritte in die richtige Reihenfolge und schickt dir meine Checkliste gegen Apple-Ablehnungen.

Häufige Fragen

Was bedeutet „Guideline 2.3.1 - Performance - Hidden Features“?

Apple ist der Meinung, dass deine App eine versteckte, ruhende oder in den Review-Notizen fehlende Funktion enthält. Die Nachricht kann sich auch auf Code beziehen, der die App nach dem Review ändern kann, manchmal zusammen mit einer Ablehnung nach 2.5.2.

Erlaubt Apple EAS Update?

Die Lizenz erlaubt heruntergeladenen interpretierten Code, solange er den Hauptzweck der App nicht ändert. Korrigieren, ja. Eine ungeprüfte Funktion hinzufügen, nein.

Darf man Feature Flags in einer iOS-App verwenden?

Ja, wenn alles, was sie anzeigen können, geprüft wurde. Schalte jeden Schalter für das Review ein und beschreibe ihn in den Notizen.

Muss man einen Demo-Modus dem Reviewer melden?

Ja. Ein eingebauter Demo-Modus braucht die vorherige Zustimmung von Apple und muss alle Funktionen zeigen.

Darf man während des Reviews ein Remote-Update veröffentlichen?

Nichts verbietet es ausdrücklich. Aber der Reviewer würde es beim ersten Start nicht sehen, und es schafft eine Lücke zur geprüften Version. Ich verzichte immer darauf.