Eine App-Store-Ablehnung kommt als Nachricht in App Store Connect an: eine Guideline-Nummer, ein paar Sätze des Prüfers, oft ein Screenshot des Bildschirms, an dem es gescheitert ist. Sie ist kein Urteil über Ihre App oder Ihr Konto. Apples App Review hat 2025 mehr als 9,1 Millionen Einreichungen bearbeitet, die meisten innerhalb von 24 Stunden, und ein großer Teil der ersten Einreichungen kommt mindestens einmal zurück. Was zählt, ist, was Sie in der Stunde nach der Nachricht tun.
Diese Entscheidung läuft auf drei Fragen hinaus. Hat der Prüfer recht? Braucht die Korrektur einen neuen Build oder nur eine Änderung am Store-Eintrag? Und wenn Sie anderer Meinung sind: Antworten Sie, oder legen Sie Einspruch ein? Dieser Leitfaden beantwortet sie der Reihe nach: wie eine Ablehnung Sie erreicht und was die Status bedeuten, die acht Gründe, die die meisten Ablehnungen abdecken, die drei möglichen Reaktionen und eine Checkliste für die erneute Einreichung.
Wenn Sie noch früher im Prozess stehen, deckt unser Leitfaden, wie Sie eine App im App Store veröffentlichen, den gesamten Weg vom Entwicklerkonto bis zur Veröffentlichung ab; dieser Artikel beginnt an dem Tag, an dem die Prüfung negativ zurückkommt.
Wie eine Ablehnung Sie erreicht und was die Status bedeuten
App Review kombiniert automatische Kontrollen, die Abstürze, die Nutzung privater APIs und Malware erkennen, mit einem menschlichen Prüfer, der Ihren Build installiert, den Store-Eintrag öffnet, Ihre Prüfnotizen liest und die App so nutzt, wie es ein Kunde täte. Wenn etwas fehlschlägt, schreibt der Prüfer eine Nachricht im Resolution Center von App Store Connect, und die Version wechselt den Status. Drei Status sind wichtig:
- Rejected. Das Binary selbst hat ein Problem: ein Absturz, eine fehlende Funktion, ein Berechtigungsproblem. Sie müssen fast immer einen neuen Build hochladen.
- Metadata Rejected. Der Build ist in Ordnung, der Store-Eintrag nicht. Screenshots, Beschreibung, Keywords, Datenschutzangaben oder Prüfnotizen müssen geändert werden, was Sie direkt in App Store Connect erledigen und ohne neuen Build erneut einreichen.
- Developer Rejected. Sie haben die Version selbst zurückgezogen, etwa um einen Build zu ersetzen. Nichts zu beantworten.
Die acht Gründe hinter den meisten Ablehnungen bei der ersten Einreichung
Die App Review Guidelines umfassen fünf Kapitel und Dutzende Regeln, aber die Ablehnungen, die eine erste Einreichung tatsächlich erhält, konzentrieren sich auf eine Handvoll. Hier sind sie, mit dem, was der Prüfer gesehen hat, und dem, was es behebt.
| Guideline | Was der Prüfer gesehen hat | Was es behebt |
|---|---|---|
| 2.1 Performance | Die App ist auf dem Gerät des Prüfers beim Start oder in einem zentralen Ablauf abgestürzt | Auf dem TestFlight-Binary reproduzieren, auf mehreren Geräten und iOS-Versionen, und beheben. Nichts anhängen; einen neuen Build hochladen. |
| 2.1 App completeness | Ein Demo-Konto, das nicht funktioniert, Platzhalterinhalte, eine Funktion mit dem Vermerk „demnächst verfügbar“ | Einen funktionierenden Login mit realistischen Daten in den App Review Information hinterlegen; Platzhalter entfernen oder fertigstellen. |
| 2.3 Accurate metadata | Screenshots oder Beschreibung zeigen Funktionen, die nicht im Build sind | Metadata Rejected: Screenshots und Texte an die App anpassen, denselben Build erneut einreichen. |
| 4.2 Minimum functionality | Eine Website in einem Rahmen oder eine App, die zu wenig tut, um eine native Installation zu rechtfertigen | Nativen Mehrwert ergänzen: Offline-Nutzung, Benachrichtigungen, Gerätefunktionen, ein Erlebnis, das die Website nicht bietet. |
| 4.3 Spam | Eine App, die eine andere dupliziert, von Ihnen oder aus einer Vorlage, in einer gesättigten Kategorie | Deutlich differenzieren oder die Varianten zu einer einzigen App zusammenführen. |
| 5.1.1 Data collection and storage | Fehlende URL der Datenschutzerklärung, App-Privacy-Angaben, die der App widersprechen, Berechtigungsabfragen ohne Begründung, fehlende Tracking-Abfrage | Die Erklärung veröffentlichen, die Angaben an das anpassen, was die App wirklich erhebt, für jede Berechtigung einen Zwecktext schreiben, die App-Tracking-Transparency-Abfrage anzeigen, wenn Sie tracken. |
| 3.1.1 In-app purchase | Digitale Inhalte oder Abonnements, die außerhalb von Apples In-App-Kauf verkauft werden | In-App-Kauf für digitale Güter nutzen; externe Zahlung bleibt für physische Güter und außerhalb der App genutzte Dienstleistungen erlaubt. |
| 1.5 Developer information | Eine Support-URL, die einen Fehler liefert, oder eine Seite ohne Kontaktmöglichkeit | Metadata Rejected: die Support-URL auf eine erreichbare Seite mit Kontaktformular oder E-Mail-Adresse zeigen lassen. |
Der Sonderfall der Web-Wrapper
Guideline 4.2 ist diejenige, die Gründer überrascht, die ihre Website in eine App verpackt haben. Apples Haltung ist konsequent: Wenn die App die Website in einer WebView ist, ohne etwas, das der Browser nicht könnte, gehört sie nicht in den App Store. Die Lösung ist keine bessere Beschreibung, sondern Funktionalität. Offline-Zugriff, Push-Benachrichtigungen, Kamera- oder Standortfunktionen, eine native Navigation, die die Website nicht hat. Wenn das Projekt als Web-App begonnen hat, ist der ehrliche Weg ein echter nativer Build, und deshalb trennt unser Leitfaden zum Erstellen einer Mobile-App ohne Programmieren Tools, die nativen Code erzeugen, von Tools, die eine Website einpacken.
Wie Sie reagieren: korrigieren, antworten oder Einspruch einlegen
Die Nachricht wie eine Checkliste lesen
Bevor Sie irgendetwas entscheiden, ziehen Sie aus der Nachricht die Guideline-Nummer, den genauen Schritt, den der Prüfer beschreibt, das oben vermerkte Gerät samt iOS-Version und jeden angehängten Screenshot heraus. Dann reproduzieren Sie es selbst auf demselben Build über TestFlight. In der Hälfte der Fälle hat der Prüfer recht, und Sie hatten es nicht gesehen; in einem Viertel der Fälle ist der Prüfer auf eine Umgebung gestoßen, die Sie nicht getestet haben, etwa eine frische Installation ohne Daten; der Rest ist eine echte Meinungsverschiedenheit.
Korrigieren und erneut einreichen
Bei einem Status Metadata Rejected bearbeiten Sie den Store-Eintrag in App Store Connect und klicken auf erneut einreichen: kein neuer Build, und die zweite Prüfung geht meist schnell. Bei einem Status Rejected laden Sie einen korrigierten Build hoch, wählen ihn in derselben Version aus und reichen erneut ein. In beiden Fällen schreiben Sie eine kurze Notiz im Resolution Center, was sich geändert hat. Prüfer lesen sie, und sie lenkt die zweite Prüfung auf die Korrektur, statt bei null anzufangen.
Antworten, wenn der Prüfer sich irrt
Wenn Sie das Problem nicht reproduzieren können oder die Guideline nicht zutrifft, antworten Sie im Resolution Center, statt denselben Build stillschweigend erneut einzureichen. Bleiben Sie sachlich: die genauen Schritte, die Sie ausgeführt haben, Gerät und Version, eine Bildschirmaufnahme, die die Funktion in Aktion zeigt, die zu verwendenden Zugangsdaten. Wenn der Prüfer missverstanden hat, was die App tut, erklären Sie den Anwendungsfall in zwei Sätzen. Sie können im selben Thread auch einen Telefonanruf von App Review anfordern; das geht nicht schnell, löst aber die Gespräche, die schriftlich nicht weiterkommen.
Einspruch beim App Review Board
Ein Einspruch ist für eine Meinungsverschiedenheit über die Guideline selbst gedacht, nicht über einen Sachverhalt. Er geht über das in der Ablehnung verlinkte Formular an das App Review Board und dauert Tage, manchmal länger. Nutzen Sie ihn, nachdem die Antwort im Resolution Center gescheitert ist, und schreiben Sie ihn für jemanden, der Ihre App nie gesehen hat: was sie tut, welche Guideline genannt wurde, warum sie Ihrer Ansicht nach nicht zutrifft. Wenn sich die Guideline kürzlich geändert hat oder Sie den Eindruck haben, dass sie uneinheitlich angewendet wird, sagen Sie das und nennen Sie Beispiele.
Beschleunigte Prüfung
Apple gewährt eine beschleunigte Prüfung für die Behebung eines kritischen Fehlers in einer veröffentlichten App oder für ein zeitkritisches Ereignis, nicht für eine verspätete Erstveröffentlichung. Eine Anfrage für einen Launch wird abgelehnt und kostet einen Tag. Wenn Ihre Frist real ist, bleibt als einziger Hebel, früh einzureichen und jede Nachricht innerhalb von Stunden zu beantworten.
Eine Checkliste gegen die zweite Ablehnung
Die meisten zweiten Ablehnungen wiederholen die erste oder legen das nächste Problem offen, zu dem der Prüfer nicht gekommen war, weil das erste die Prüfung gestoppt hatte. Gehen Sie diese Liste vor der erneuten Einreichung einmal durch:
- Das TestFlight-Binary öffnet sich bei einer frischen Installation, ohne Daten, auf der ältesten iOS-Version, die Sie unterstützen.
- Das Demo-Konto in den App Review Information meldet sich an, und die Daten dahinter sehen echt aus.
- Jede Berechtigungsabfrage hat einen Zwecktext, der sagt, was die Funktion mit den Daten macht.
- Die URL der Datenschutzerklärung öffnet sich, und die App-Privacy-Angaben passen zu den SDKs in der App.
- Screenshots zeigen Bildschirme, die es in diesem Build gibt, in den richtigen Gerätegrößen.
- Jeder digitale Kauf läuft über In-App-Kauf, und jeder physische ist eindeutig physisch.
- Support-URL und Marketing-URL laden und bieten eine Kontaktmöglichkeit.
- Platzhaltertexte, Test-Buttons und „demnächst verfügbar“-Bildschirme sind verschwunden.
- Die Prüfnotizen erklären alles Ungewöhnliche: eine Hardware-Anforderung, eine regional beschränkte Funktion, einen Login über einen Drittanbieter.
Wenn Sie mit dem Mobile-App-Baukasten von Cadrant bauen, sind die Teile der Pipeline, die Ablehnungen auf Build-Ebene verursachen, für Sie erledigt: Das native Binary wird auf Ihrem Expo-Konto kompiliert und signiert, bei Ihrem App Store Connect eingereicht, und die App ist eine echte Expo-Anwendung statt einer eingepackten Website, womit Guideline 4.2 aus dem Spiel bleibt. Was bei Ihnen bleibt, ist genau diese Checkliste: der Store-Eintrag, die Datenschutzangaben, das Demo-Konto und ein Durchlauf über TestFlight, bevor Sie auf Einreichen klicken. Die Dokumentation zur Veröffentlichung listet die App-Store-Connect-Schritte der Reihe nach auf.
Die Kurzfassung
- Eine Ablehnung ist eine Nachricht mit einer Guideline-Nummer; der Status sagt Ihnen, ob der Build oder der Store-Eintrag das Problem ist.
- Acht Guidelines erklären die meisten ersten Ablehnungen: Abstürze, Demo-Konto, Metadaten, Mindestfunktionalität, Spam, Datenschutz, In-App-Kauf, Support-URL.
- Korrigieren und erneut einreichen, wenn der Prüfer recht hat; mit Belegen antworten, wenn die Fakten falsch sind; Einspruch nur, wenn die Guideline selbst strittig ist.
- Antworten Sie noch am selben Tag, und gehen Sie die Checkliste vor jeder erneuten Einreichung durch.
So gehandhabt kostet eine Ablehnung ein oder zwei Tage, nicht den Launch. Die Apps, die stecken bleiben, sind die, die denselben Build erneut einreichen und auf einen anderen Prüfer hoffen.