Das Wichtigste in Kürze
Apples App Review Guidelines enthalten jetzt eine eigenständige Regel 2.5.19, die versteckte, schlafende oder undokumentierte Funktionen verbietet und das Verbergen per Code-Obfuskation als Grund für die Entfernung der App und die Kündigung des Entwickler-Accounts wertet. Seriöse Apps sind nicht das Ziel, doch jedes Team, das nach der Freigabe Verhalten zuschaltet, sollte seine iOS-Entwicklung und seinen Release-Prozess prüfen, bevor der nächste Build ins Review geht.
Was hat sich an den App Review Guidelines geändert?
Apple hat am 16. Oktober drei Änderungen veröffentlicht. Die wichtigste ist die neue Richtlinie 2.5.19: Apps dürfen keine „hidden, dormant, or undocumented features“ enthalten, und ihre Funktionalität soll „für Endnutzer und App Review klar“ sein. Der Versuch, undokumentierte Funktionen im Binary zu verbergen – etwa durch Code-Obfuskation oder andere Methoden –, ist laut Regel ein Grund, die App zu entfernen und den Entwickler-Account zu kündigen.
Apple versteht die Regel als Klarstellung eines lange bestehenden Verbots: Apps, die im Review harmlos wirken und sich nach der Freigabe verändern, nennt Apple Bait-and-Switch. Die zweite Änderung erweitert Richtlinie 1.2 zu nutzergenerierten Inhalten: Sie nennt nun ausdrücklich nicht einvernehmliche intime Bilder und erfasst KI-Apps zur Inhaltserstellung. Die dritte betrifft Abschnitt 5: Apps, die nachweislich Menschenhandel oder die Ausbeutung von Kindern ermöglichen, fliegen aus dem App Store und werden auch für den alternativen Vertrieb gesperrt – den Weg, über den Apple in der EU Apps außerhalb seines Stores zulässt.
The Verge, das am selben Tag berichtete, benannte das eigentliche Ziel: sogenannte „Nudify“-Apps, die als Fotoeditor durchs Review gehen und später Funktionen für sexualisierte Deepfakes freischalten.
Betrifft Regel 2.5.19 Feature Flags und Remote Config?
Nicht als Technik, aber sie hebt die Messlatte für deren Einsatz. Feature Flags, gestaffelte Rollouts, A/B-Tests und serverseitig gesteuerte UI sind Standard in der Mobile-Entwicklung, und Apples Text erwähnt sie nicht. Verboten ist Funktionalität, die App Review nicht sehen kann: Codepfade, die während des Reviews dunkel bleiben und danach aktiviert werden, oder Fähigkeiten, die im Binary bewusst getarnt sind.
Die praktische Grenze ist die Wesentlichkeit. Einen geprüften Checkout-Flow für 10 % der Nutzer freizuschalten, ist ein Rollout. Eine Funktion zu aktivieren, die der geprüfte Build nie gezeigt hat – eine neue Zahlungsart, ein Chat-Modul, ein Content-Generator –, verändert, was die App tut. Der zweite Fall gehört als neuer Build ins Review, mit Beschreibung in den App-Review-Notizen und Demo-Zugangsdaten, die die Funktion erreichen. Obfuskation zum Schutz geistigen Eigentums bleibt üblich; riskant wird sie, sobald sie Verhalten statt Implementierung verbirgt.
Was müssen KI-Bild- und UGC-Apps tun?
Richtlinie 1.2 gilt jetzt für Apps, mit denen Nutzer Inhalte „erstellen, generieren, hochladen, teilen oder anderweitig beitragen“, und nennt nicht einvernehmliche intime Bilder neben Urheberrechtsverletzungen und Mobbing. Laut Apples Ankündigung müssen solche Apps diese Inhalte proaktiv verhindern und entfernen, auch wenn sie mit KI-Werkzeugen erzeugt wurden. Die bisherigen Pflichten bleiben: Filter für anstößige Inhalte, ein Meldeweg mit zeitnaher Reaktion und die Möglichkeit, missbräuchliche Nutzer zu blockieren. Wer keine angemessenen Schutzmaßnahmen hat oder Verstöße nach Hinweis nicht behebt, riskiert die Entfernung nach dem Developer Code of Conduct.
Für jede App rund um Bildgenerierung oder -bearbeitung heißt das: Moderation ist kein Backlog-Punkt für nach dem Launch mehr. Prompt-Filter, Klassifizierung der Ausgaben und ein funktionierender Melde- und Löschprozess müssen in dem Build stecken, den App Review sieht.
Warum verschärft Apple das Review gerade jetzt?
Apple begründet das Update mit Betrug, der erst nach der Freigabe aktiv wird. Laut Ankündigung hat Apple im vergangenen Jahr mehr als 150.000 Apps mit Sicherheitsproblemen gestoppt und mehr als 193.000 Entwickler-Accounts wegen Betrugs und Missbrauchs gekündigt; einige Fälle betrafen koordinierte Operationen, die schädliche Inhalte bis nach dem Review versteckten. Generative KI macht dieses Muster billiger: Eine harmlos wirkende Foto-App kann jederzeit ein anderes Modell oder eine andere Prompt-Pipeline vom Server laden. Mit einer eigenen, nummerierten Regel hat Apple eine klare Grundlage für Sanktionen auf Account-Ebene.
Was das für Softwareteams in den USA und der EU bedeutet
Für die meisten Produktteams ändert die Regel eher die Dokumentation als die Architektur. Das Risiko steckt in Release-Praktiken, die ohne Blick aufs Review gewachsen sind: Kill Switches, die nebenbei unveröffentlichte Funktionen freischalten, Experimente, die ein ganzes neues Modul hinter einem Flag ausliefern, oder White-Label-Builds, deren kundenspezifische Funktionen erst nach der Freigabe per Konfiguration aktiviert werden. All das sollte dokumentiert oder als geprüfter Build ausgeliefert werden.
Die Sanktion auf Account-Ebene verändert die Risikorechnung für Unternehmen, die mehrere Apps unter einem Entwickler-Account veröffentlichen. Ein einziger Verstoß gegen 2.5.19 in einem Produkt kann nach Apples Wortlaut den gesamten Account gefährden – ein Argument für einen Release-Verantwortlichen, der die Review-Notizen mit dem abgleicht, was die Flags tatsächlich steuern.
Was bedeutet Regel 2.5.19 für App-Teams im DACH-Raum?
In Deutschland und Österreich kommt der EU-Rahmen hinzu. Apps, die über alternative Marktplätze nach dem Digital Markets Act (DMA) vertrieben werden, durchlaufen weiterhin Apples Notarisierung, und der neue Abschnitt 5 erstreckt die Sperre ausdrücklich auf diesen Vertriebsweg – der DMA-Kanal ist also kein Schlupfloch. Wer KI-Bildfunktionen anbietet, muss die neuen Pflichten aus 1.2 zusätzlich mit der DSGVO beim Umgang mit Personenbildern, mit den Moderationspflichten aus dem Digital Services Act (DSA, in Deutschland beaufsichtigt von der Bundesnetzagentur als Koordinator für digitale Dienste) und mit den Transparenzpflichten des EU AI Act für Deepfakes zusammenbringen.
In der Schweiz gilt der DMA nicht, alternative Marktplätze gibt es dort nicht – für Schweizer Nutzer bleibt der App Store der einzige Weg, und Regel 2.5.19 wirkt dort unmittelbar. Für Agenturen und Mittelständler im DACH-Raum, die White-Label-Apps für mehrere Kunden unter einem Account betreiben, lohnt sich deshalb jetzt ein Flag-Inventar pro Mandant, bevor das nächste Release eingereicht wird.
Checkliste vor der nächsten App-Store-Einreichung
- Flags inventarisieren. Listen Sie jeden Remote-Config-Schlüssel und jedes Feature Flag auf und markieren Sie, welche Funktionen freischalten, die der geprüfte Build nicht enthält.
- Ehrliche Review-Notizen schreiben. Beschreiben Sie serverseitig gesteuertes Verhalten, gestaffelte Funktionen und länderspezifische Features und geben Sie App Review einen Demo-Account, der sie erreicht.
- Neue Funktionen als neuen Build ausliefern. Würde ein Flag wesentlich verändern, was die App tut, reichen Sie ein Update ein, statt es in Produktion umzulegen.
- Umfang der Obfuskation prüfen. Obfuskation soll Implementierungsdetails schützen, nicht unveröffentlichte Funktionen.
- UGC- und KI-Moderation härten. Generative Apps brauchen Prompt- und Ausgabefilter, Meldung, Blockieren und einen dokumentierten Löschprozess im eingereichten Build.
- Release-Verantwortlichen benennen. Eine Person bestätigt, dass Build, Flags und Review-Notizen dieselbe App beschreiben.
Häufige Fragen
Was hat Apple am 16. Oktober 2026 an den App Review Guidelines geändert?
Apple hat Richtlinie 2.5.19 eingeführt, die versteckte, schlafende oder undokumentierte Funktionen und deren Verschleierung im Binary, etwa durch Code-Obfuskation, verbietet. Richtlinie 1.2 erfasst nun ausdrücklich nicht einvernehmliche intime Bilder, auch KI-generierte. Abschnitt 5 wurde so angepasst, dass Apps, die Menschenhandel oder Kindesausbeutung ermöglichen, entfernt und auch für den alternativen Vertrieb gesperrt werden.
Sind Feature Flags und Remote Config im App Store jetzt verboten?
Nein, Feature Flags als Technik hat Apple nicht verboten. Regel 2.5.19 zielt auf Funktionen, die vor App Review verborgen oder nach der Freigabe zugeschaltet werden. Sicher ist: nur geprüfte Funktionen im Binary ausliefern, serverseitig gesteuertes Verhalten in den Review-Notizen beschreiben und einen neuen Build einreichen, wenn ein Flag wesentlich verändern würde, was die App tut.
Was droht bei einem Verstoß gegen Regel 2.5.19?
Laut Apple ist das Verbergen undokumentierter Funktionen ein Grund, die App aus dem App Store zu entfernen und den Entwickler-Account zu kündigen. Die Ankündigung ergänzt, dass Apps, die sich nach der Freigabe verändern, aus dem Apple Developer Program entfernt werden können.
Gilt Regel 2.5.19 auch für Apps aus alternativen Marktplätzen in der EU?
Apps aus alternativen Marktplätzen nach dem DMA durchlaufen weiterhin Apples Notarisierung, und der aktualisierte Abschnitt 5 dehnt die Sperre ausdrücklich auf den alternativen Vertrieb aus. Wer in Deutschland oder Österreich über einen solchen Marktplatz vertreibt, sollte daher dieselben Review-Regeln einplanen wie im App Store.
Was müssen KI-Bild- und UGC-Apps nach der neuen Richtlinie 1.2 tun?
Apps, mit denen Nutzer Inhalte erstellen, generieren, hochladen oder teilen, einschließlich KI-Apps, müssen nicht einvernehmliche intime Bilder proaktiv verhindern und entfernen, anstößige Inhalte filtern, einen Meldeweg anbieten und das Blockieren missbräuchlicher Accounts ermöglichen. Wer Verstöße nach Hinweis nicht behebt, riskiert die Entfernung.
Quellen
Apple Developer — Strengthening App Review Guidelines against nonconsensual intimate imagery and bait-and-switch apps (October 16, 2026)
Apple Developer — App Review Guidelines (updated October 16, 2026)
The Verge — Apple’s updated App Store rules go after ‘nudify’ AI apps (October 16, 2026)