App-Store-Ablehnung 2.1 App Completeness: Testplan für den Release-Build vor der erneuten Einreichung (2026)

Eine App-Store-Ablehnung nach 2.1 App Completeness bedeutet, dass der Prüfer Ihre App nicht so nutzen konnte wie ein Kunde. Vielleicht ist sie abgestürzt, hat Platzhalterinhalte gezeigt, ihn an einem Login-Bildschirm blockiert oder einen In-App-Kauf versteckt. Die Lösung ist selten eine einzige Codezeile. Bevor Sie erneut einreichen, führen Sie einen kurzen Testplan mit dem Release-Build durch – mit einer Neuinstallation und genau den Zugangsdaten, die Sie App Review geben. Dieser Beitrag geht diesen Plan Schritt für Schritt durch und zeigt, wie andere Entwickler dieselbe Ablehnung behoben haben.

Was prüft die App-Store-Richtlinie 2.1 App Completeness?

Richtlinie 2.1 prüft, ob der eingereichte Build eine fertige, funktionierende App ist. Dazu gehören vollständige Metadaten, funktionierende Links, ein Demo-Login, ein laufendes Backend sowie In-App-Käufe, die der Prüfer finden und nutzen kann.

Apples App Review Guidelines teilen 2.1 in zwei Teile. 2.1(a) besagt, dass Einreichungen „finale Versionen mit allen nötigen Metadaten und voll funktionsfähigen URLs“ sein sollen und dass Platzhaltertexte und leere Websites zu entfernen sind. Außerdem sollen Sie auf einem Gerät auf Fehler und Stabilität testen und „Angaben zum Demo-Konto beifügen (und Ihren Backend-Dienst einschalten!), wenn Ihre App einen Login enthält“. Apple „lehnt unvollständige App-Bundles und Binaries ab, die abstürzen oder offensichtliche technische Probleme zeigen“. 2.1(b) besagt, dass In-App-Käufe „vollständig, aktuell, für den Prüfer sichtbar und funktionsfähig“ sein müssen. Ist ein konfigurierter Kauf in der App nicht auffindbar, erklären Sie den Grund in Ihren Review-Notizen.

Diese Ablehnung ist häufig. Auf Apples Seite Preparing for App Review heißt es: „Im Durchschnitt betreffen über 40 % der ungelösten Probleme Richtlinie 2.1: App Completeness, die Abstürze, Platzhalterinhalte, unvollständige Informationen und mehr abdeckt.“

Warum deckt das Testen des Debug-Builds keine 2.1-Probleme auf?

Ein Debug-Build läuft nicht so wie die Kopie des Prüfers. Der Prüfer installiert einen mit Distributionszertifikat signierten Release-Build auf einem sauberen Gerät – ohne gespeicherte Sitzung und ohne Debug-Abkürzungen.

Ihr Simulator ist bereits angemeldet. Ihre lokale API zeigt vielleicht auf einen Staging-Server, der nie ausfällt. Debug-Flags überspringen die Paywall, und Feature-Flags sind standardmäßig aktiv. Der Prüfer hat nichts davon. Apples Review-Seite fordert zudem, „gründlich auf Geräten mit der neuesten Software zu testen“ – der Prüfer nutzt also womöglich ein neueres iOS als Ihr Testgerät.

TestFlight kommt der Umgebung des Prüfers am nächsten. Laut der TestFlight-Übersicht können Sie bis zu 100 interne Tester aus Ihrem App-Store-Connect-Team und bis zu 10.000 externe Tester hinzufügen. Ein Build lässt sich bis zu 90 Tage testen. Laden Sie genau den Build hoch, den Sie einreichen wollen, installieren Sie ihn über TestFlight auf einem Gerät, auf dem die App noch nie lief, und testen Sie diese Kopie.

Was sollte ein Testplan für den Release-Build vor der erneuten Einreichung abdecken?

Ein Testplan für den Release-Build prüft jede Stelle, an der ein neuer Prüfer hängen bleiben kann: Start, Berechtigungen, Login, Backend, Inhalte, Links, Käufe, Netzwerkausfälle und iPad. Führen Sie die Schritte der Reihe nach mit dem TestFlight-Build aus und notieren Sie jedes Ergebnis, damit Sie es in Ihren Review-Notizen zitieren können.

1. Saubere Installation auf dem neuesten iOS. Löschen Sie jede frühere Kopie, installieren Sie über TestFlight und starten Sie ohne gespeicherten Zustand. Führen Sie drei Kaltstarts durch und prüfen Sie, dass das Onboarding nicht abstürzt.
2. Jede Berechtigungsanfrage einmal ablehnen. Lehnen Sie Mitteilungen, Standort, Kamera und Tracking ab. Die App sollte trotzdem einen nutzbaren Bildschirm erreichen. Prüfen Sie außerdem, ob die Info.plist für jede geschützte Ressource, die die App oder ihre SDKs nutzen, eine Nutzungsbeschreibung enthält.
3. Mit genau den Demo-Zugangsdaten anmelden. Kopieren Sie sie aus App Store Connect, nicht aus Ihrem Passwortmanager. Das Konto sollte realistische Daten enthalten, keine E-Mail-Verifizierung erfordern und keine Zwei-Faktor-Authentifizierung nutzen, die an Ihr eigenes Handy gebunden ist.
4. Sicherstellen, dass das Backend produktiv ist und läuft. Der Build muss auf Produktiv-Endpunkte zeigen. Rate Limits, IP-Allowlists und Geoblocking dürfen keinen Prüfer aussperren. Richtlinie 2.1(a) fordert Sie ausdrücklich auf, Ihren Backend-Dienst einzuschalten.
5. Jeden Tab und jeden Bildschirm durchgehen. Achten Sie auf Lorem ipsum, „Demnächst verfügbar“-Bildschirme, leere Zustände ohne Erklärung, Testbilder und Buttons ohne Funktion.
6. Jeden Link antippen. Dazu gehören Datenschutzerklärung, Support, Nutzungsbedingungen und alle Web-Views. Apple schreibt: „Ein Link zum Nutzersupport mit aktuellen Kontaktdaten und ein Link zu Ihrer Datenschutzerklärung sind für alle Apps erforderlich.“
7. Jeden In-App-Kauf öffnen. Melden Sie sich mit einem neuen Konto an. Prüfen Sie, ob jedes mit der Version eingereichte Produkt mit Preis erscheint, in der Sandbox gekauft werden kann und ob „Käufe wiederherstellen“ funktioniert.
8. Mit langsamem oder unterbrochenem Netzwerk testen. Schalten Sie mitten in einem Ablauf den Flugmodus ein. Eine klare Fehlermeldung ist in Ordnung. Ein endloser Ladeindikator oder ein Absturz nicht.
9. iPad prüfen, falls unterstützt. Läuft die App auf dem iPad, starten Sie sie dort und stellen Sie sicher, dass das Layout den Nutzer nicht festsetzt.

Das Demo-Konto aus Schritt 3 verursacht mehr wiederholte Ablehnungen als jeder andere Schritt. Unser Leitfaden zum Einrichten eines Demo-Kontos für das App Store Review zeigt, wie Sie eines anlegen, das dauerhaft funktioniert.

Wie ordnen Sie eine 2.1-Ablehnungsmeldung der richtigen Korrektur zu?

Um eine 2.1-Ablehnung einer Korrektur zuzuordnen, lesen Sie den Satz nach der Richtliniennummer. Er benennt das Symptom, und jedes Symptom verweist auf einen Schritt im Testplan.

Angenommen, eine Habit-Tracking-App wird mit der Meldung „Wir konnten die App nicht prüfen, da sie beim Start abgestürzt ist“ abgelehnt. Ein zweiter Hinweis besagt, dass der Prüfer die In-App-Käufe nicht finden konnte. Die folgende Tabelle ordnet häufige Symptome einer Ursache, einem Test und einer Korrektur zu.

Eine allgemeinere Methode, beliebige Ablehnungsmeldungen zu lesen, finden Sie unter App-Store-Ablehnung beheben: Richtlinie für Richtlinie.

Wie sahen die 2.1-Ablehnungen anderer Entwickler aus?

Öffentlich dokumentierte 2.1-Fälle folgen demselben Muster. Die App funktioniert in der Umgebung des Entwicklers und scheitert beim Prüfer an etwas, das nur eine Neuinstallation oder der Login eines Fremden aufdecken würde.

• Absturz durch eine fehlende Nutzungsbeschreibung. Im Solar2D-Forum erhielt ein Entwickler die Meldung „Wir konnten die App nicht prüfen, da sie beim Start abgestürzt ist“ – auf einem iPhone 13 mini mit iOS 18.3.2, obwohl die App in TestFlight lief. Ein anderes Mitglied fand im angehängten Absturzprotokoll: „Diese App ist abgestürzt, weil sie ohne Nutzungsbeschreibung auf datenschutzrelevante Daten zugreifen wollte.“ Der Entwickler berichtete: „Nach dem Hinzufügen von NSUserTrackingUsageDescription ging sie durch.“
• Social Logins, die der Prüfer nicht nutzen konnte. Ein Entwickler in den Apple Developer Forums berichtete von wiederholten 2.1-Ablehnungen, weil die Prüfer „die Social Logins nicht nutzen konnten“. Er hatte Demo-Konten für Apple und Google angegeben, doch die Anmeldung mit der Apple-ID erforderte einen Bestätigungscode, der an das Handy des Entwicklers ging. Apple-Mitarbeiter antworteten, App Review werde sich direkt melden. Eine öffentliche Lösung wurde nicht gepostet.
• In-App-Käufe „konnten im eingereichten Binary nicht gefunden werden“. In einem Thread der RevenueCat Community wurde ein Entwickler abgelehnt, weil ein Monatsabo im Binary nicht gefunden wurde, obwohl Sandbox-Käufe funktionierten. Ein Helfer schrieb, eine ähnliche Ablehnung sei durch eine Antwort mit ausführlicher Anleitung und Screenshots aller Wege zur Paywall gelöst worden. RevenueCat-Mitarbeiter rieten, jedes eingereichte Produkt auf der Standard-Paywall anzuzeigen und StoreKit-Testdateien aus dem Archive-Schema herauszuhalten.

In allen drei Fällen bestanden die eigenen Tests des Entwicklers. Der Fehler trat erst aus der Ausgangslage eines Prüfers auf – ohne 2FA-Handy, ohne vorherige Sitzung und ohne zu wissen, wo die Paywall ist. Genau diese Ausgangslage stellt der obige Testplan nach.

Was sollte nach einer 2.1-Ablehnung in den App-Review-Notizen stehen?

Review-Notizen nach einer 2.1-Ablehnung sollten funktionierende Demo-Zugangsdaten enthalten, auflisten, was sich seit dem abgelehnten Build geändert hat, und genau angeben, wo In-App-Käufe und nicht offensichtliche Funktionen zu finden sind.

Laut Apples Review-Seite gehören Kontodaten und spezielle Konfigurationen in den Abschnitt „App Review Information“. Erfordert eine Funktion Hardware oder eine schwer einzurichtende Umgebung, sollten Sie „darauf vorbereitet sein, ein Demo-Video oder die Hardware bereitzustellen“. Richtlinie 2.3.1(a) ergänzt, dass neue Funktionen in den Notes for Review „konkret“ beschrieben werden müssen und dass „allgemeine Beschreibungen abgelehnt werden“. Eine kurze, strukturierte Notiz funktioniert gut:

Demo account: review@example.com / (password)
Account is pre-verified, has no 2FA and has 30 days of sample data.

Fixes since last submission (2.1):
- Launch crash on fresh install fixed (tested build 42 on latest iOS, clean device).
- In-app purchases: Settings > Upgrade shows Monthly and Yearly.
- Backend is production and will stay live during review.

Non-obvious features:
- Widgets: long-press Home Screen > add "Streaks" widget.

Schließen rechtliche oder sicherheitsbezogene Pflichten ein Demo-Konto aus, erlaubt Richtlinie 2.1(a) einen integrierten Demo-Modus – aber nur mit vorheriger Genehmigung durch Apple, und dieser Modus muss den vollen Funktionsumfang der App zeigen. Wechseln Sie nicht ohne diese Genehmigung zu einem Demo-Modus.

Wie reichen Sie nach einer 2.1-Ablehnung erneut ein oder legen Einspruch ein?

Um nach einer 2.1-Ablehnung erneut einzureichen, laden Sie den getesteten Build hoch oder wählen ihn aus, antworten App Review in App Store Connect mit Ihren Änderungen, aktualisieren die Review-Notizen und reichen erneut ein. Legen Sie nur Einspruch ein, wenn Sie glauben, dass der Prüfer die App missverstanden hat.

1. Prüfen Sie, ob die Build-Nummer, die der Version in App Store Connect zugeordnet ist, mit dem getesteten TestFlight-Build übereinstimmt.
2. Antworten Sie auf die Ablehnungsmeldung mit einer kurzen Zusammenfassung jeder Korrektur. Bei einem Kauf- oder Navigationsproblem fügen Sie eine Schritt-für-Schritt-Anleitung und Screenshots hinzu.
3. Aktualisieren Sie den Abschnitt „App Review Information“ mit aktuellen Zugangsdaten und Notizen.
4. Reichen Sie zur Prüfung ein. Stand Oktober 2026 prüft Apple nach eigenen Angaben in der Regel „mindestens 50 % der Einreichungen in weniger als 24 Stunden und 90 % in weniger als 48 Stunden“.

Wenn Sie glauben, dass Apple falsch liegt, können Sie über die App-Review-Seite Einspruch beim App Review Board einlegen. Nennen Sie konkrete Gründe, warum die App die Richtlinien erfüllt, und „reichen Sie nur einen Einspruch pro nicht bestandener Einreichung ein“. Bei einer 2.1-Ablehnung ist es aber meist schneller, das Problem auf einem sauberen Gerät zu reproduzieren, als zu argumentieren. Wenn Sie die erneute Einreichung lieber abgeben möchten: Unser App-Store-Einreichungsservice umfasst Review-Vorbereitung und Umgang mit Ablehnungsfeedback für beide Stores für $599, Gebühren für Entwicklerkonten separat.

2.1-Probleme tauchen in späteren Updates oft wieder auf: ein neues Feature-Flag, ein rotierter API-Schlüssel oder ein abgelaufenes Demo-Konto. Nehmen Sie diesen Testplan in Ihre Release-Routine auf, zusammen mit der App-Store-Einreichungscheckliste. Bei Updates begrenzt ein stufenweiser Release (Phased Release), wie viele Nutzer ein übersehener Fehler erreicht. Für eine zweite Meinung zu einem abgelehnten Build schreiben Sie mit der Ablehnungsmeldung an yagyeshsrbobde@gmail.com.