Apple App Review Guidelines 2026: Wie prüfen unabhängige Entwickler selbst?

Am 16.10.2026 veröffentlichte Apple Änderungen an den App Review Guidelines: Die Abschnitte 2.3.14 und 2.5.19 behandeln Werbematerialien sowie verborgene, ruhende oder nicht erläuterte Funktionen (Änderungshinweis von Apple). Das bedeutet nicht, dass jede App sofort umgebaut werden muss. Für die Selbstprüfung der Apple App Review Guidelines 2026 sollten Entwickler zuerst Werbematerial und Funktionssichtbarkeit abgleichen und unklare Abläufe in den Review Notes erklären.

Dieser Beitrag richtet sich an: Einzelentwickler und kleine Teams, die eine neue App oder ein Update einreichen und Store-Aussagen mit der tatsächlichen App abgleichen müssen.
Besonders relevant ist er, wenn Funktionen per Remote-Konfiguration, Feature-Schalter oder stufenweiser Freigabe aktiviert werden.
Auch Verantwortliche für Werbematerialien finden hier eine Abgrenzung zu Screenshots und App-Vorschauen.

Zuletzt aktualisiert am 21.10.2026; abgeglichen mit Apples Änderungshinweis, den aktuellen App Review Guidelines und den Dokumenten zu App-Store-Materialien und Review-Informationen.

Apple App Review Guidelines 2026 selbst prüfen: zuerst die Regeländerung einordnen

Apple weist in seinem Änderungshinweis darauf hin, dass Abschnitt 2.3.14 Anforderungen an Werbematerialien ergänzt und Abschnitt 2.5.19 die Behandlung verborgener, ruhender oder nicht offengelegter Funktionen näher beschreibt. Der Hinweis erklärt außerdem, dass die betreffenden Regeln zuvor unter Abschnitt 2.3.1 eingeordnet waren (Apple-Mitteilung zur Überarbeitung; aktuelle App Review Guidelines).

Für die Prüfung zählt der Text der jeweils einschlägigen Richtlinie, nicht eine Vermutung darüber, wie Apple einen Einzelfall entscheiden wird. Die Änderungen sind daher ein Anlass, konkrete Risiken zu kontrollieren, aber keine pauschale Aufforderung, sämtliche Apps umzuschreiben. Eine Funktion, die nur später freigeschaltet werden soll, ist nicht automatisch unzulässig; entscheidend ist, ob sie tatsächlich verborgen oder nicht ausreichend erläutert ist und wie sie sich für Nutzer und Prüfer darstellt.

Diese Unterscheidung verhindert zwei entgegengesetzte Fehler: Ein Team sollte weder notwendige Erläuterungen ignorieren, noch aus einer Richtlinienänderung eine allgemeine Pflicht zur Änderung von Architektur oder Code ableiten. Die folgende Prüfung trennt deshalb drei Fragen: Was verspricht das Material? Was kann die eingereichte App tatsächlich? Und kann das Review-Team den relevanten Ablauf nachvollziehen?

Schritt 1: Werbematerial auf Aussage, Zielgruppe und Nachweis prüfen

Bei der Prüfung von App-Store-Werbematerialien geht es nicht nur darum, ob ein Bild technisch korrekt hochgeladen wurde. Entwickler sollten kontrollieren, ob das Material zum Inhalt, zu den Funktionen und zur Marke der App passt und ob es für die vorgesehene Zielgruppe geeignet ist. Behauptungen, die sich in der App nicht nachvollziehen lassen, können einen falschen Eindruck vermitteln. Dasselbe gilt für die Darstellung anderer Apps, wenn Nutzer dadurch eine Verbindung oder Funktion annehmen könnten, die tatsächlich nicht besteht. Abschnitt 2.3.14 ist dafür der zentrale Prüfpunkt in Apples Richtlinien (App Review Guidelines, Abschnitt 2.3).

Prüfen Sie jede Aussage nicht isoliert, sondern anhand eines konkreten Nachweises. Wenn ein Werbemotiv etwa eine bestimmte Funktion oder ein Ergebnis verspricht, sollte sich dieses Ergebnis in der eingereichten App-Version auffinden lassen. Ist eine Funktion nur unter bestimmten Bedingungen verfügbar, gehören diese Bedingungen in eine verständliche Beschreibung statt in eine verkürzte Aussage, die für alle Nutzer zu gelten scheint.

Auch Preisangaben verdienen eine gesonderte Kontrolle. Enthält ein Motiv einen konkreten Preis oder Rabatt, muss die Aussage zur tatsächlichen Angebotslage passen und darf nicht als zeitloser oder allgemein verfügbarer Vorteil erscheinen, wenn sie das nicht ist. Ändert sich ein Angebot, sollten betroffene Materialien und Metadaten vor der Einreichung erneut geprüft werden. Apple veröffentlicht die Anforderungen an die Verwaltung von App-Store-Materialien in seiner Dokumentation zu App-Store-Assets.

Die Tabelle ersetzt nicht Apples jeweilige Vorgaben für das konkrete Material. Screenshots unterliegen eigenen Anforderungen, die Apple in der Dokumentation zu Screenshots erläutert. Für App-Vorschauen gelten wiederum eigene technische und inhaltliche Vorgaben, die in den Spezifikationen für App-Vorschauen beschrieben sind. Ein Screenshot ist also nicht einfach ein Werbemotiv, und ein Video erhält nicht allein dadurch einen anderen Prüfmaßstab, dass es im Store an einer anderen Stelle erscheint.

Prüfhinweis: Wenn eine Aussage nur mit einer langen Erklärung im Beschreibungstext verständlich wird, ist das ein Warnsignal für das Motiv selbst. Die Ergänzung im Storetext kann fehlende Klarheit in einer stark verkürzten Werbeaussage nicht zuverlässig ersetzen.

Schritt 2: Remote-Funktionen auf Sichtbarkeit statt auf Implementierungsart prüfen

Eine Remote-Konfiguration oder ein Feature-Schalter ist zunächst eine technische Umsetzung. Allein die Wahl dieser Technik belegt nicht, dass eine App gegen die Richtlinien verstößt. Das Risiko entsteht, wenn eine Funktion im eingereichten Paket vorhanden ist, aber für Nutzer oder App Review verborgen bleibt, nicht erläutert wird oder sich nicht wie beschrieben prüfen lässt. Abschnitt 2.5.19 behandelt verborgene, ruhende oder nicht offengelegte Funktionen; Entwickler sollten den tatsächlichen Ablauf daher an diesem Wortlaut messen.

Erstellen Sie zunächst ein Inventar der Funktionen, die im eingereichten Build enthalten sind. Dazu gehören auch Funktionen, die standardmäßig ausgeschaltet sind, auf eine Serverantwort warten oder nur für bestimmte Konten sichtbar werden. Notieren Sie jeweils, wie ein Nutzer die Funktion erreicht, welche Voraussetzungen gelten und ob das Review-Team den Zugang erhält. Eine gestaffelte Freigabe kann ein normaler Produktablauf sein; wenn der Zugang für die Prüfung fehlt und die Funktion nicht erläutert wird, kann das dagegen Rückfragen auslösen.

Die Tabelle ist eine redaktionelle Prüfhilfe und keine zusätzliche Apple-Regel. Sie soll verhindern, dass „remote gesteuert“ mit „automatisch verborgen“ gleichgesetzt wird. Ausschlaggebend sind die sichtbare Nutzererfahrung, die Übereinstimmung mit den Angaben und die Möglichkeit, den beschriebenen Zustand nachzuvollziehen.

Lassen sich remote konfigurierte oder noch nicht freigeschaltete Funktionen als verborgene Funktionen einordnen?

Nicht allein aufgrund der technischen Umsetzung. Eine Remote-Konfiguration kann beispielsweise dazu dienen, eine Funktion kontrolliert bereitzustellen. Sie wird aber erklärungsbedürftig, wenn die App eine Funktion enthält, die in der Oberfläche oder den Store-Angaben nicht erkennbar ist, oder wenn die eingereichte Version sie anders darstellt, als sie später tatsächlich arbeitet. Eine pauschale Aussage, jede serverseitige Aktivierung sei unzulässig, lässt sich aus der bloßen Implementierungsform nicht ableiten.

Prüfen Sie deshalb, ob die Funktion in der App auffindbar ist, ob Bedingungen und Einschränkungen verständlich sind und ob App Review sie mit den bereitgestellten Informationen erreichen kann. Wenn ein serverseitiger Schalter die Funktion während der Prüfung deaktiviert, obwohl die App sie als verfügbar darstellt, sollte das Team den Zustand entweder korrigieren oder die Abweichung in den Review Notes erklären. Das ist eine Vorsichtsmaßnahme zur Nachvollziehbarkeit, keine Zusage, dass eine bestimmte Konfiguration akzeptiert wird.

Schritt 3: Store-Versprechen mit der eingereichten Version abgleichen

Widersprüche entstehen oft schrittweise: Ein Screenshot bleibt nach einer Änderung veraltet, eine Funktion wird umbenannt, eine Einschränkung kommt hinzu oder ein Werbemotiv zeigt einen Zustand, der in der aktuellen Version nicht erreichbar ist. Legen Sie deshalb die Store-Beschreibung, Werbematerialien, Screenshots, App-Vorschau und den tatsächlich eingereichten Build nebeneinander. Apple beschreibt in den Richtlinien, dass App-Angaben und App-Verhalten keinen irreführenden Eindruck erzeugen sollen (App Review Guidelines).

Achten Sie besonders auf Bedingungen, die in Werbeaussagen häufig verkürzt werden: Ist ein Konto erforderlich? Ist eine Funktion erst nach einer Anmeldung verfügbar? Gilt sie nur für einen bestimmten Plan, eine Region oder eine Gerätekonfiguration? Wenn solche Einschränkungen für das Verständnis eines Kernversprechens wesentlich sind, sollten sie nicht erst während des Reviews sichtbar werden.

Für die Prüfung der Store-Angaben ist die Version relevant, die tatsächlich zur Begutachtung eingereicht wird. Kontrollieren Sie daher auch, ob die gewählte Build-Version und die Angaben zur Plattform zusammenpassen; Apples Referenz zu Plattform- und Versionsinformationen in App Store Connect hilft bei der Einordnung dieser Versionsdaten.

Schritt 4: Review Notes so schreiben, dass ein fremder Prüfer den Ablauf findet

Ein Funktionsteil kann für das Team selbsterklärend sein und für eine externe prüfende Person dennoch unzugänglich bleiben. Das gilt etwa für Funktionen hinter einem Login, einem bestimmten Rollenprofil, einem Einladungsprozess oder einer Remote-Konfiguration. Die Review Notes sollten daher nicht nur die Funktion benennen, sondern ihren Zugang und den erwarteten Zustand beschreiben. Apple verlangt vollständige Informationen, wenn sie für die Prüfung erforderlich sind; die offiziellen Hinweise zur Vervollständigung der Review-Informationen führen die Angaben auf, die Entwicklern dafür zur Verfügung stehen.

Eine brauchbare Notiz beantwortet diese Fragen in sachlicher Reihenfolge:

1. Wo beginnt der relevante Ablauf?
2. Welche Zugangsdaten oder Voraussetzungen sind nötig?
3. Welche Schritte führen zur fraglichen Funktion?
4. Welche Darstellung oder Antwort sollte App Review sehen?
5. Gibt es eine Einschränkung, die bei der Interpretation des Ablaufs wichtig ist?

Vermeiden Sie unbestimmte Hinweise wie „Funktion im Menü prüfen“. Nennen Sie stattdessen den Menüpfad, die nötige Rolle und gegebenenfalls, ob eine serverseitige Konfiguration aktiv sein muss. Enthält die App sensible Testdaten, sollten dafür geeignete Testkonten und klar begrenzte Berechtigungen verwendet werden. Zugangsdaten gehören in die dafür vorgesehenen Felder und nicht in öffentliche Store-Texte oder allgemeine Dokumentationen.

Ein internes Prüfprotokoll macht außerdem sichtbar, ob die Angaben mit dem getesteten Build übereinstimmen. Die folgenden Befehle dokumentieren lokal den Arbeitsbaum und die verfügbare Xcode-Umgebung; sie beweisen nicht, dass Apple genau diesen Build erhalten hat. Die beispielhaften Ausgaben sind Platzhalter, keine Vorgabe für konkrete Versionsstände.

git status --short
xcodebuild -version

Beispiel einer internen Notiz:

Build geprüft: [Build-Kennung aus App Store Connect]
Werbematerial: geprüft / Korrektur erforderlich
Funktion mit Remote-Konfiguration: [Zustand dokumentiert]
Zugang für Review: [Testkonto oder Zugangsweg]
Prüfpfad: [Menü und Schritte]
Abweichungen zur Store-Beschreibung: [keine / erläutert]

Bewahren Sie das Protokoll zusammen mit der Freigabe für die Einreichung auf. Entscheidend ist die Verbindung zwischen Store-Aussage, getesteter App und eingereichtem Build, nicht allein das Vorhandensein eines Versionsbefehls auf dem Entwicklungsrechner.

Schritt 5: Risiken getrennt bewerten und vor der Einreichung beheben

Die Selbstprüfung wird unzuverlässig, wenn unterschiedliche Befunde als ein einziges „Review-Risiko“ notiert werden. Ein irreführendes Werbemotiv ist ein anderes Problem als eine Funktion, die nicht erreichbar ist; eine fehlende Review-Erklärung ist wiederum nicht automatisch ein Codefehler. Dokumentieren Sie jeden Befund separat und halten Sie die zugehörige Store-Aussage, App-Funktion oder Review-Information fest.

Eine einfache interne Bewertung kann ohne Vorhersage des Review-Ausgangs auskommen:

• Kritisch für die Einreichung: Eine zentrale Werbeaussage ist in der App nicht belegbar oder ein angekündigter Kernablauf ist im eingereichten Build nicht erreichbar.
• Erklärungsbedürftig: Die Funktion ist vorhanden, aber Zugang, Verfügbarkeit oder Remote-Zustand sind für Außenstehende nicht klar.
• Zu aktualisieren: Screenshot, Vorschau oder Beschreibung zeigt einen früheren Stand.
• Nachweisbar: Material, App-Verhalten und Review-Pfad stimmen überein und sind dokumentiert.

Diese Kategorien sind eine Arbeitsmethode, keine offizielle Apple-Klassifikation. Sie helfen dabei, die Korrektur der Ursache zuzuordnen: Material überarbeiten, Funktion zugänglich machen, Metadaten präzisieren oder Review Notes ergänzen. Eine erfolgreiche interne Prüfung kann Unsicherheiten reduzieren, garantiert aber keine Annahme durch App Review, da die Beurteilung vom konkreten Inhalt und Einzelfall abhängt.

Für Teams, die mehrere Builds oder Plattformvarianten pflegen, sollte das Prüfprotokoll die genaue Einreichung identifizieren. Stimmen Build-Kennung, getesteter Stand und ausgewählte Version in App Store Connect nicht überein, lässt sich selbst eine sorgfältige Materialprüfung nicht verlässlich auf die eingereichte App übertragen. Zur Vorbereitung der technischen Seite kann die Übersicht zu einem Mac-Entwicklungsplatz für Build-Prüfungen als Einstieg dienen; sie ersetzt jedoch nicht die Prüfung des tatsächlichen Einreichungsstands.

Vor dem Versand: eine knappe Freigabeprüfung durchführen

Führen Sie die Abschlusskontrolle in einer festen Reihenfolge aus, damit ein korrigiertes Motiv nicht mit einer noch veralteten App-Version zusammen eingereicht wird:

1. Materialien erfassen: Werbematerial, Screenshots, Vorschau und Store-Beschreibung in einer Prüfliste sammeln.
2. Aussagen belegen: Für jedes konkrete Versprechen den passenden App-Bildschirm oder Ablauf nennen.
3. Funktionen inventarisieren: Auch deaktivierte, kontogebundene und remote gesteuerte Funktionen aufnehmen.
4. Zugänge testen: Den Review-Pfad mit den bereitgestellten Zugangsdaten durchspielen, nicht nur mit einem Entwicklerkonto.
5. Abweichungen beheben oder erklären: Veraltetes Material korrigieren; nicht offensichtliche Bedingungen in Review Notes aufnehmen.
6. Einreichung abgleichen: Sicherstellen, dass geprüfter Build und ausgewählter App-Store-Connect-Build übereinstimmen.

Die maßgeblichen Regeln sollten vor der Veröffentlichung erneut in Apples aktuellen Richtlinien und Dokumenten geprüft werden, insbesondere wenn Apple nach dem redaktionellen Abgleich Ergänzungen veröffentlicht. Eine Prüfliste bleibt nur dann belastbar, wenn sie zur aktuell eingereichten Version gehört und nicht aus einem früheren Release übernommen wird.

Eine geeignete macOS-Umgebung wählen, ohne Review-Sicherheit zu versprechen

Für die hier beschriebene Richtlinienprüfung ist nicht zwingend ein neu gekaufter Mac erforderlich. Wer bereits eine verlässliche macOS-Umgebung und genügend lokalen Speicher für den eigenen Entwicklungsablauf hat, kann Build, Store-Material und Review-Zugänge dort kontrollieren. Eine lokale Maschine bietet direkten Zugriff auf angeschlossene Geräte, erfordert aber, dass Wartung, Speicher und Verfügbarkeit im Team selbst organisiert werden.

Ein remote gemieteter Mac kann sinnvoll sein, wenn ein Team für die Einreichung einen getrennten macOS-Build- und Prüfplatz benötigt oder nicht dauerhaft eigene Mac-Hardware bereitstellen möchte. Er nimmt dem Team jedoch weder die Verantwortung für sichere Zugangsdaten noch die Pflicht, den finalen Build selbst zu verifizieren. Wer den Ablauf auf einer entfernten Maschine prüft, sollte deshalb zusätzlich festhalten, welcher Build exportiert und welcher Build anschließend in App Store Connect ausgewählt wurde. Für einen zeitlich begrenzten oder ausgelagerten Prüfplatz lässt sich beispielsweise ein Mac-mini-Angebot für Hongkong prüfen; für dauerhaft hohe Auslastung, lokale Geräteanschlüsse oder eine eng integrierte Arbeitsstation kann ein eigener Mac die passendere Wahl bleiben.

Der entscheidende Unterschied liegt nicht darin, dass eine bestimmte Umgebung eine Genehmigung wahrscheinlicher machen würde. Eine lokale Einrichtung bindet Hardware und Pflegeaufwand, während eine gemietete Remote-Umgebung zusätzliche Zugangskontrollen und eine klare Übergabe des Builds verlangt. Wenn ein Team nur für Build-Erstellung und Versionsabgleich eine stabile macOS-Umgebung benötigt, kann die Miete eines Mac von ViewMini die Anschaffung eines ausschließlich dafür vorgesehenen Geräts vermeiden. Sie ist aber kein Ersatz für eine korrekte Werbeaussage, nachvollziehbare Funktionen oder vollständige Review Notes – genau diese Punkte müssen vor jeder Einreichung unabhängig geprüft werden.