App Review Guidelines Oktober 2026: Was 1.2, 2.3.14, 2.5.19 und 3.1.1(a) für Ihre App bedeuten

Die Änderungen der App Review Guidelines im Oktober 2026 hat Apple am 16. Oktober 2026 im Beitrag Updated App Review Guidelines are now available angekündigt. Zwei Richtlinien sind neu (2.3.14 und 2.5.19), drei Passagen wurden umformuliert (1.2, 3.1.1(a) und Abschnitt 5), und die Abschnitte Before You Submit und After You Submit verlinken jetzt auf weitere Dokumentation. Im Folgenden finden Sie jede Änderung verständlich erklärt, wer handeln muss, und eine Checkliste für Ihre nächste Einreichung.

Was hat sich am 16. Oktober 2026 in den App Review Guidelines geändert?

Apple hat Richtlinie 2.3.14 für Creative Assets und Richtlinie 2.5.19 für versteckte Funktionen hinzugefügt. Außerdem wurden 1.2 (nutzergenerierte Inhalte), 3.1.1(a) (externe Kauflinks) und Abschnitt 5 (Rechtliches) präzisiert. Apples Änderungsprotokoll listet die Anpassungen so auf:

Laut Apple werden Übersetzungen „innerhalb eines Monats auf der Apple-Developer-Website verfügbar sein“. Stand Oktober 2026 sollten Sie die englischen App Review Guidelines heranziehen, sobald eine übersetzte Fassung davon abweicht.

Was verlangt die neue Richtlinie 2.5.19 zu versteckten Funktionen?

Richtlinie 2.5.19 verlangt, dass jede Funktion in Ihrem Binary für Nutzer und App Review sichtbar und dokumentiert ist. Das Verbergen von Funktionen, auch durch Obfuskation, kann zur Entfernung der App und zur Kündigung des Entwicklerkontos führen.

Der genaue Wortlaut: „Bauen Sie keine versteckten, ruhenden oder undokumentierten Funktionen in Ihre App ein; die Funktionalität Ihrer App sollte für Endnutzer und App Review klar erkennbar sein. Der Versuch, undokumentierte Funktionen im App-Binary zu verbergen, etwa durch Code-Obfuskation oder andere Methoden, ist ein Grund für die Entfernung Ihrer App aus dem App Store und die Kündigung Ihres Entwicklerkontos.“ Apple bezeichnet dies als langjährige Praxis, bisher stand die Regel jedoch in 2.3.1. Die aktuelle 2.3.1(a) verlangt weiterhin, dass neue Funktionen „im Abschnitt Notes for Review konkret beschrieben“ werden. Ablehnungen wegen versteckter Funktionen sollten sich nun stattdessen auf 2.5.19 berufen.

In der Praxis heißt das: Führen Sie in Ihren Review-Notizen jede Funktion auf, die durch einen Server-Schalter, einen Einladungscode, einen QR-Scan, eine Region oder eine Kontostufe freigeschaltet werden kann. Wenn ein Flag eine Funktion erst nach der Freigabe aktiviert, schalten Sie sie entweder im geprüften Build ein oder lassen den Code bis zu der Version weg, mit der die Funktion erscheint.

Welche Apps sind von den Änderungen an Richtlinie 1.2 betroffen?

Richtlinie 1.2 gilt jetzt für jede App, in der Nutzer Inhalte „erstellen, generieren, hochladen, teilen oder anderweitig beitragen“ können, und nennt Social Media, UGC-Plattformen und KI-Apps zur Inhaltserstellung ausdrücklich. Solche Apps müssen anstößiges Material filtern, eine Meldefunktion mit zeitnaher Reaktion anbieten, das Blockieren missbräuchlicher Nutzer ermöglichen und Kontaktinformationen veröffentlichen.

Der überarbeitete Text nennt „nicht einvernehmliche intime Bilder“ neben Verletzungen geistigen Eigentums und Mobbing. Ergänzt wurde: „Entwickler, die keine angemessenen Schutzmaßnahmen umsetzen oder festgestellte Verstöße nach Hinweis nicht beheben, können als Verstoß gegen den Developer Code of Conduct gewertet werden.“ Auch eine KI-Bild- oder Avatar-App, die Inhalte nur für den jeweiligen Nutzer generiert, kann damit in den Geltungsbereich fallen. Prompt- und Ausgabefilter, Meldefunktion und veröffentlichte Kontaktdaten gehören in den eingereichten Build, nicht auf die Roadmap.

Was sagt Richtlinie 2.3.14 über Creative Assets?

Laut Richtlinie 2.3.14 müssen Creative Assets einen Bezug zu Inhalt, Funktionalität oder Marke Ihrer App haben, den üblichen Metadaten-Regeln folgen und für alle Altersgruppen geeignet sein. Verboten sind unangemessene Inhalte, irreführende Verweise auf andere Apps, nicht überprüfbare Behauptungen und „konkrete oder reduzierte Preisangaben“.

Creative Assets sind die Bild- und Videoassets, die Apple am 5. Oktober 2026 eingeführt hat. Laut Apples App Store asset best practices erscheinen sie „in iOS 27 und iPadOS 27 und neuer, unter anderem auf Ihrer Produktseite, in Suchergebnissen und wenn Ihre App vorgestellt wird“. Diese Seite geht weiter als die Richtlinie: Sie empfiehlt, auf Website-URLs, Copyright-Symbole, Logos anderer Plattformen und Apple-Auszeichnungen wie „Editor's Choice“ zu verzichten. Außerdem heißt es dort, Assets „müssen einer Altersfreigabe von 4+ entsprechen, auch wenn Ihre App höher eingestuft ist“. Ein Header mit „Diese Woche 50 % Rabatt“ oder „Die Nr. 1 unter den Budget-Apps“ verstößt gegen 2.3.14.

Was hat sich bei den externen Kauflinks in Richtlinie 3.1.1(a) geändert?

Richtlinie 3.1.1(a) hat keinen eigenen Punkt mehr für das Music Streaming Services Entitlement. Dieses Entitlement steht jetzt im Punkt zu den StoreKit External Purchase Link Entitlements, und laut Text dürfen Links zu „einem zulässigen Ziel“ führen. Die zugelassenen Ziele können je nach Region variieren.

Die Regeln dazu, wo Links erlaubt sind, wurden mit diesem Update nicht geändert. Die Entitlements sind weiterhin auf bestimmte Storefronts beschränkt. Die US-Storefront bleibt die Ausnahme, in der Buttons, externe Links und andere Handlungsaufforderungen auch ohne Entitlement erlaubt sind. Wenn Sie bereits eines der beiden Entitlements nutzen, prüfen Sie, ob Ihr Link in jeder Storefront, in der Sie ausliefern, weiterhin auf ein zulässiges Ziel führt.

Wie beheben Entwickler Ablehnungen wegen versteckter Funktionen und UGC in der Praxis?

Öffentlich dokumentierte Fälle zeigen: Ablehnungen nach der alten 2.3.1-Formulierung zu versteckten Funktionen und nach 1.2 wurden meist gelöst, indem jede Funktion und jede Schutzmaßnahme für den Prüfer leicht auffindbar gemacht oder Widerspruch eingelegt wurde. Reine Code-Änderungen halfen selten.

• Im März 2026 berichtete ein Entwickler in den Apple Developer Forums, dass eine native Social-Wecker-App nach „Guideline 2.3.1(a) - Hidden Features“ und 4.2 abgelehnt wurde. WebViews seien nur für Datenschutzerklärung, Nutzungsbedingungen und FAQ verwendet worden, und er legte Widerspruch ein. App Review antwortete, das App Review Board habe reagiert. Daraufhin bat der Entwickler um Nennung der konkret betroffenen Screens; eine Lösung wurde nicht gepostet.
• In einem Flutter-GitHub-Issue erhielten mehrere Entwickler für einfache Apps die Meldung „Wir haben festgestellt, dass Ihre App versteckte Funktionen enthält“. Ein Flutter-Contributor nannte das Framework „eine falsche Fährte“ und verwies auf undokumentierte APIs im App-Code oder in Plugins. Zwei Entwickler meldeten eine Freigabe nach Widerspruch, ohne ihren Code zu ändern.
• Ein Entwickler in den Apple Developer Forums wurde trotz EULA, Filterung, Meldefunktion und Blockieren nach 1.2 abgelehnt. Er sollte Nutzungsbedingungen mit „null Toleranz für anstößige Inhalte“ vereinbaren und „Meldungen anstößiger Inhalte innerhalb von 24 Stunden bearbeiten“. Eine zweite Ablehnung forderte zusätzlich eine 18+-Altersfreigabe, sofortiges Entfernen von Beiträgen und Kontaktinformationen in der App. Er reagierte, indem er jede Schutzmaßnahme dokumentierte und Admin-Zugangsdaten in den Review-Notizen bereitstellte.

Fazit: In allen drei Fällen konnten die Prüfer Funktionen nicht sehen oder verifizieren, die die Entwickler für offensichtlich hielten. Unter 2.5.19 und der strengeren 1.2 leisten Review-Notizen und Demo-Konto genauso viel wie der Code. Wie Sie beides einrichten, zeigt unser Leitfaden zum Demo-Konto für das App Store Review.

Was sollten Sie vor Ihrer nächsten Einreichung prüfen?

Prüfen Sie vor Ihrem nächsten Build Feature Flags, UGC-Schutzmaßnahmen, Creative Assets und externe Links anhand des neuen Textes und schreiben Sie dann Review-Notizen, die auf jeden dieser Punkte verweisen. Die folgende Checkliste deckt die Änderungen vom Oktober 2026 ab.

1. Listen Sie jedes serverseitig gesteuerte Flag, jeden Remote-Config-Schlüssel und jedes versteckte Menü auf. Schalten Sie jedes davon für den Prüfer ein oder entfernen Sie den Code, den es steuert.
2. Beschreiben Sie jede neue Funktion konkret in den Notes for Review, wie es 2.3.1(a) verlangt, einschließlich des Wegs zu allem, was hinter Einladungen, Scans oder kostenpflichtigen Stufen liegt.
3. Wenn Nutzer posten, chatten oder Inhalte generieren können, stellen Sie sicher, dass Filterung, Meldefunktion, Blockieren und veröffentlichte Kontaktdaten im Build enthalten sind, und dokumentieren Sie Ihren Prozess zur Bearbeitung von Meldungen.
4. Bei KI-Bild- oder Videogenerierung ergänzen Sie Prompt- und Ausgabefilter, die sexuelle Darstellungen realer Personen blockieren, und geben Nutzern eine Möglichkeit, Ergebnisse zu melden.
5. Prüfen Sie jedes Creative Asset auf Preise, Rabatte, URLs, Auszeichnungsbehauptungen, Logos anderer Plattformen und alles, was über eine 4+-Freigabe hinausgeht.
6. Wenn Sie ein External Purchase Link oder Music Streaming Entitlement nutzen, stellen Sie sicher, dass der Link in jeder Storefront zu einem zulässigen Ziel führt.
7. Lesen Sie die englischen Guidelines für jeden Abschnitt, auf den Sie sich stützen, erneut, da Übersetzungen bis zu einem Monat hinterherhinken können.

Praxisbeispiel: Nehmen wir eine KI-Avatar-App mit öffentlicher Galerie und einem „Pro“-Stilpaket, das nach dem Launch per Remote Config freigeschaltet wird. Nach dem neuen Text braucht sie Moderation und eine Meldefunktion für die Galerie (1.2). Das Pro-Paket muss entweder im geprüften Build sichtbar sein oder bis zu einer späteren Version zurückgehalten werden (2.5.19). Ihr Header-Asset für iOS 27 darf nicht „Pro jetzt 40 % günstiger“ sagen (2.3.14). Wenn Sie bereits mit einer Ablehnung zu tun haben, erklärt unser Leitfaden zur Behebung nach Richtlinie, wie Sie in App Store Connect antworten. Wenn Sie vor der Einreichung ein zweites Paar Augen möchten, sehen Sie sich unsere Leistungen an.