Guideline 2.1: App-Store-Ablehnung verstehen und beheben

Die Guideline 2.1 ist die Regel, an der die meisten Einreichungen scheitern. Apple schreibt es selbst auf seiner App-Review-Seite: Im Schnitt betreffen über 40 % der ungelösten Probleme die 2.1, also die Regel für Abstürze, Platzhalterinhalte und unvollständige Informationen.

Dieser Artikel behandelt nur diese eine Regel: was sie abdeckt, ihre zwei Varianten, wie der Reviewer deine App testet und was du ihm antwortest. Dazu drei Ablehnungen, die ich mit meinen eigenen Apps kassiert habe. Für den Überblick über alle Ablehnungsgründe lies lieber warum Apple eine App ablehnt.

Was ist die Guideline 2.1 App Completeness?

Die Guideline 2.1 verlangt, dass die an Apple geschickte App eine finale, vollständige Version ist: keine Abstürze, keine toten Links, kein Platzhaltertext, ein Demo-Account, falls die App eine Anmeldung verlangt, und sichtbare, funktionierende In-App-Käufe. Wenn der Reviewer deine App nicht komplett durchgehen kann, gibt es eine 2.1-Ablehnung.

Der offizielle Text steht in den App Review Guidelines, Abschnitt 2 „Performance“. Er besteht aus zwei Absätzen.

2.1(a) verlangt, dass jede Einreichung eine finale Version ist, mit allen Metadaten und funktionierenden URLs. Platzhaltertext, leere Websites und alle temporären Inhalte müssen vor dem Einreichen weg sein. Die App muss auf einem echten Gerät auf Bugs und Stabilität getestet worden sein. Verlangt sie eine Anmeldung, stellst du einen Demo-Account bereit und lässt deinen Server laufen. Ein eingebauter Demo-Modus kann diesen Account ersetzen, aber nur mit vorheriger Zustimmung von Apple, und er muss alle Funktionen der App zeigen. Der Satz, der alles zusammenfasst: „We will reject incomplete app bundles and binaries that crash“.

2.1(b) betrifft In-App-Käufe: Sie müssen vollständig, aktuell, für den Reviewer sichtbar und funktionsfähig sein. Ist ein in App Store Connect konfigurierter Kauf in der App nicht auffindbar, musst du in den Review-Notizen erklären, warum.

Was die Guideline 2.1 konkret abdeckt

In der Praxis kommt eine 2.1-Ablehnung aus einem dieser Gründe:

• Ein Absturz. Beim Start, nach einer verweigerten Berechtigung, ohne Netz. Einer reicht.
• Ein toter Link. Datenschutz, Nutzungsbedingungen, Support: Jede angegebene URL wird geöffnet.
• Eine unerreichbare Funktion. Ein Button, der nirgendwohin führt, ein Pflichtbildschirm, an dem man nicht vorbeikommt, ein Onboarding ohne Ausgang. Die tückischste Form: auf deinem eigenen Handy unsichtbar.
• Ein fehlender oder abgelaufener Demo-Account. Der Reviewer hängt am Login-Bildschirm fest, oder der bereitgestellte Account funktioniert nicht mehr, oder der Server ist aus.
• Füllinhalte. Lorem ipsum, „Demnächst verfügbar“, leerer Bildschirm, sichtbare Testdaten.
• Unauffindbare In-App-Käufe. Das Abo existiert in App Store Connect, aber der Reviewer findet den Bildschirm nicht, der es verkauft, oder der Kauf schlägt in der Sandbox fehl. Die häufigsten Fehler auf Bezahlbildschirmen findest du in iOS-Paywall: 7 Anfängerfehler.

2.1 Information Needed oder 2.1(a): Was ist der Unterschied?

Nicht alle Nachrichten von Apple tragen denselben Titel, und der Unterschied ändert deine Antwort.

„Guideline 2.1 - Information Needed“ heißt, dass der Reviewer seine Prüfung nicht abschließen konnte und dir eine Frage stellt. Es fehlen Zugangsdaten, eine Erklärung, ein Weg zu einer Funktion. Das ist noch kein festgestellter Bug, sondern eine Anfrage. Manchmal reicht eine präzise Antwort in App Store Connect. Zeigt die Frage aber eine echte Blockade in der App, brauchst du einen neuen Build.

„Guideline 2.1(a) - Performance - App Completeness“ heißt, dass der Reviewer ein Problem festgestellt hat: einen Absturz, einen Bug, einen Bildschirm, der nicht reagiert. Die Nachricht nennt meist das verwendete Gerät und enthält oft einen Screenshot. Dann musst du korrigieren, einen neuen Build schicken und danach antworten.

Wie Apple deine App testet

Versetz dich in den Reviewer. Drei Punkte zählen.

Er testet auf einem Gerät, das du vielleicht nicht hast. Die Ablehnung nennt oft das Modell. Regel 2.4.1 besagt, dass iPhone-Apps nach Möglichkeit auch auf dem iPad laufen sollen, und eine fürs iPhone gebaute App wird dort im Kompatibilitätsmodus angezeigt, in einem Fenster im iPhone-Format. Meine letzten 2.1-Ablehnungen kamen von einem iPad Air: Wenn du nur auf deinem iPhone testest, siehst du nicht, was der Reviewer sieht.

Er startet mit einem ersten Start. Frische App, kein Cache, keine Sitzung, kein heruntergeladenes Update.

Das Netzwerk muss mit reinem IPv6 funktionieren. Regel 2.5.5, Nachbarin der Guideline 2.5.4 zu Hintergrundmodi, verlangt, dass die App in einem reinen IPv6-Netz voll funktioniert, und Apples Support-Seite zu IPv6 macht das seit dem 1. Juni 2016 zur Pflicht für alle eingereichten Apps. Das Risiko kommt von einer fest eingetragenen IPv4-Adresse: Apple empfiehlt, in einem reinen IPv6-Netz mit ausgeschalteten Mobilfunkdaten zu testen.

Um diese Bedingungen vor dem Einreichen nachzustellen, ist TestFlight auf mehreren Geräten am einfachsten: siehe TestFlight: deine iPhone-App testen.

Drei Ablehnungen, die ich kassiert habe, und ihre wahre Ursache

Drei aktuelle Ablehnungen meiner eigenen Apps, mit ihrer wahren Ursache.

Solys: eine Minispiel-Demo, die auf dem iPad nicht zu gewinnen war

Solys ist mein Wecker mit Minispielen. Am 18. August 2026 wird ein Build mit „2.1 Information Needed“ abgelehnt: Apple fragt nach einem Weg, die Spielmission zu überspringen. Der Reviewer testete auf einem iPad Air, mit der iPhone-App im Kompatibilitätsmodus.

Die wahre Ursache lag in der Minispiel-Demo des Onboardings. Die Hindernishöhen waren in festen Punkten angegeben. Bei der verfügbaren Kartenhöhe auf dem iPad im Kompatibilitätsmodus wurde der Durchgang schmaler als die Spielfigur: Die Demo war nicht zu gewinnen. Und der Button „Weiter“ wurde nur bei einem Sieg aktiv. Kein Ausweg: Der Reviewer konnte die App nicht sehen.

Die Korrektur: eine Geometrie proportional zur gemessenen Kartengröße und ein Link „Demo überspringen“, der nach einer Niederlage erscheint.

Die Lehre: Jeder Schritt, der eine Leistung verlangt, braucht einen bedingungslosen Ausgang. Und jeder Pflichtbildschirm wird auf dem kleinsten unterstützten Bildschirm UND auf dem iPad im Kompatibilitätsmodus getestet.

Nolera: eine Korrektur, die der Reviewer nicht sehen konnte

Am 17. September 2026 wird Nolera nach einer Prüfung auf einem iPad Air abgelehnt. Die Nachricht kombinierte die 2.1(a) mit weiteren Punkten. Die Korrektur für das gemeldete Problem war per Remote-Update (OTA) ausgeliefert worden, ohne neuen Build.

Das Problem: Beim allerersten Start sieht der Reviewer den im Build eingebetteten Code, nicht das danach heruntergeladene Update. Für ihn existierte die Korrektur nicht.

Die Lehre: Eine Korrektur für die Prüfung muss im Binary stecken, das an Apple geht.

Clic: Die Ursache lag nicht in der App

Am 16. September 2026 wird Clic abgelehnt. Die App selbst war aktuell. Die wahre Ursache lag woanders: Die online veröffentlichte Datenschutzerklärung war beim verwendeten KI-Anbieter nicht auf dem neuesten Stand. Diese Ablehnung gehört eher zum Datenschutz als zur 2.1, zeigt aber dasselbe: Die wahren Ursachen sind nicht immer die, die die Nachricht vermuten lässt.

Die Lehre: Prüf, was online ist, nicht was in deinem Repository liegt. Öffne jede angegebene URL am Tag der Einreichung.

Was du im Resolution Center antwortest

Nach einer Ablehnung wechselt deine Einreichung zu „Unresolved Issues“, und die Unterhaltung mit Apple läuft im App-Review-Bereich deiner App, den man immer noch Resolution Center nennt. Das offizielle Verfahren, um App Review zu antworten, erlaubt eine Nachricht mit höchstens 4.000 Zeichen und einem Anhang.

Schreib auf Englisch, nüchtern. Der Reviewer will drei Informationen: was blockiert hat, was sich geändert hat, wie man es prüft. Hier ist meine Vorlage (ersetze die Build-Nummer und die Korrektur durch deine):

Hello,

Thank you for your review.

Issue: the onboarding game demo could not be completed on iPad
(iPhone app running in compatibility mode), so the user could
not continue.

Fix in build 1.0.3 (42):
- The game layout now scales to the measured screen size.
- A "Skip demo" link appears after a failed attempt, so the
  onboarding can always be completed.

How to verify: launch the app, start the onboarding demo,
lose once, then tap "Skip demo".

A screen recording is attached.

Best regards,

Ein paar Regeln:

• Beantworte die gestellte Frage. Bei „Information Needed“ fang mit der exakten Antwort an, nicht mit dem Kontext.
• Nenn den Build und beschreib den Weg zum korrigierten Bildschirm, in drei oder vier Schritten.
• Häng einen Beweis an. Ein kurzes Video auf einem Gerät ähnlich dem des Reviewers erspart eine weitere Runde.
• Kein Plädoyer. Den Einspruch beim App Review Board gibt es, aber bei einer berechtigten 2.1-Ablehnung verlängert er nur die Wartezeit. Details zu den Fristen findest du in Dauer der App-Store-Prüfung.

Wenn der Grund nach dem Lesen unklar bleibt, steht das komplette Vorgehen auf der Seite von Apple abgelehnte App.

Review-Notizen und Demo-Account

Der Bereich App Review Information deiner Version in App Store Connect ist deine beste Verteidigung gegen die 2.1. Laut der offiziellen Referenz zu diesen Feldern enthält er:

• Sign-in required: Benutzername und Passwort eines Demo-Accounts. Dieser Account darf nicht ablaufen. Nutzt deine App eine Drittanbieter-Anmeldung, gib die Zugangsdaten für diesen Dienst an.
• Notes: bis zu 4.000 Bytes, in einer Sprache deiner Wahl. Alles, was beim Testen hilft.
• Contact: ein Name, eine E-Mail-Adresse und eine Nummer im internationalen Format.

Was ich immer in die Notizen schreibe:

1. Den Weg zu jedem In-App-Kauf, wie Regel 2.1(b) es verlangt.
2. Die nicht offensichtlichen Funktionen: eine Geste, eine Berechtigung, ein an eine Uhrzeit gebundener Inhalt.
3. Den Zustand des Demo-Accounts: Abonnent oder nicht, vorausgefüllte oder leere Daten.
4. Die bekannten Grenzen: Bei schwer nachzustellender Hardware oder Umgebung verlangt Apple, dass du ein Video liefern kannst.

Und eine Regel außerhalb des Formulars: Lass deinen Server während der gesamten Prüfung laufen. Ein abgeschalteter Testserver bedeutet einen Demo-Account, der nicht mehr funktioniert, also eine 2.1-Ablehnung.

Die 2.1-Checkliste vor dem Einreichen

Die, die ich vor jeder Einreichung anwende, aufgebaut auf meinen Ablehnungen:

• App frisch installiert auf dem kleinsten unterstützten iPhone, dem größten und einem iPad im Kompatibilitätsmodus
• Onboarding komplett durchlaufen, mit absichtlichem Scheitern bei jedem Schritt, der eine Leistung verlangt
• Jeder Pflichtbildschirm mit einem bedingungslosen Ausgang
• Keine Korrektur für die Prüfung nur per Remote-Update ausgeliefert
• App im Flugmodus gestartet, dann in einem reinen IPv6-Netz
• Jede angegebene URL am selben Tag geöffnet: Datenschutz, Bedingungen, Support
• Kein Platzhaltertext, kein leerer Bildschirm, keine sichtbaren Testdaten
• Demo-Account am Tag der Einreichung getestet, ohne Ablaufdatum, Server läuft
• Jeder In-App-Kauf aus der App heraus gefunden und in der Sandbox getestet, Wiederherstellung inklusive
• Review-Notizen, die angeben, wo die Käufe und die nicht offensichtlichen Funktionen sind

Wenn das deine erste Veröffentlichung ist, findest du alle vorherigen Schritte unter eine App im App Store veröffentlichen.

Deine Einreichung mit jemandem vorbereiten, der diese Ablehnungen schon kassiert hat

Das Apple Review Kit bündelt meine Checkliste vor dem Einreichen, die Vorlagen für die Notizen an den Tester und Claude-Code-Skills, die dein Projekt prüfen, bevor du es einreichst.

Du hast gerade eine 2.1-Ablehnung bekommen? Das Kit hilft dir auch, die zitierte Regel zu finden, zu verstehen, was sie verlangt, und liefert ein Beispiel für Korrektur und Antwort. Wenn wir uns deine Einreichung sofort gemeinsam ansehen sollen, buch eine Stunde mit mir, per Video.

Niemand kann garantieren, dass Apple deine App annimmt. Was ich tun kann: dir helfen, die 2.1-Ablehnungen zu vermeiden, die mich schon jeweils einen Prüfzyklus gekostet haben.

Du hast deine App noch nicht eingereicht? Die kostenlose Diagnose schickt dir meine Anti-Ablehnungs-Checkliste für Apple, Regel 2.1 inklusive, und sagt dir, was vor dem Einreichen noch zu tun ist. Wenn du sie noch baust, zeigt die Startseite, wie du eine mobile App erstellst, mit der Prüfung von Anfang an im Blick.

Häufige Fragen

Was bedeutet „Guideline 2.1 - Information Needed“?

Der Reviewer konnte seine Prüfung nicht abschließen und stellt dir eine Frage: Zugangsdaten, eine Erklärung, einen Weg zu einer Funktion. Antworte präzise in App Store Connect. Zeigt die Frage eine echte Blockade in der App, wie bei Solys, behebe sie und schick einen neuen Build.

Brauche ich nach einer 2.1-Ablehnung einen neuen Build?

Bei einem Absturz, einem Bug oder einem blockierenden Bildschirm ja: Die Korrektur muss im Binary stecken. Ein Remote-Update reicht nicht, weil der Reviewer beim ersten Start den eingebetteten Code sieht. Bei einer bloß fehlenden Information kann eine Antwort genügen.

Meine App verlangt eine Anmeldung: Was gebe ich dem Reviewer?

Einen Demo-Account, der nicht abläuft, eingetragen im Bereich App Review Information, und einen Server, der während der gesamten Prüfung läuft. Ein eingebauter Demo-Modus kann diesen Account nur mit vorheriger Zustimmung von Apple ersetzen, und er muss alle Funktionen zeigen.

Kann eine 2.1-Ablehnung von etwas anderem als der App kommen?

Ja. Eine tote URL im Eintrag, ein abgelaufener Demo-Account, ein abgeschalteter Server oder ein falsch konfigurierter In-App-Kauf reichen aus. Und manchmal liegt die wahre Ursache, wie bei Clic, online und nicht im Code: Prüf alles, was der Reviewer öffnen kann.