Zum Hauptinhalt springen
← Zurück zu den Artikeln

Ressourcen für Entwickler

Warum Apple Ihre App-Store-Screenshots abgelehnt hat (und wie Sie es beheben)

Abgelehnt nach Richtlinie 2.3.3 oder von App Store Connect blockiert? Jeder häufige Ablehnungsgrund für App-Store-Screenshots — falsche Größen, Splash-Screens, Android-Rahmen — und die genaue Lösung.

Ihr Build hat die Prüfung bestanden, Ihr Code ist in Ordnung — und die Ablehnungs-E-Mail dreht sich um Ihre Screenshots. Es ist eine der frustrierendsten Arten, bei einem Release Tage zu verlieren, denn Screenshot-Ablehnungen sind fast immer vermeidbar und fast nie klar erklärt.

Screenshots scheitern an zwei verschiedenen Toren, und die Lösung hängt davon ab, welches Sie erwischt hat:

  1. App Store Connect verweigert den Upload — ein technischer Validierungsfehler, noch bevor die Prüfung beginnt.
  2. App Review lehnt die Einreichung ab — ein menschlicher Prüfer beanstandet Ihre Metadaten, meist unter Nennung einer Richtliniennummer wie 2.3.3.

Dieser Leitfaden behandelt beide, Ablehnung für Ablehnung, mit den Richtlinienverweisen und dem schnellsten Weg zurück zu „In Prüfung".


Tor 1: App Store Connect nimmt die Datei nicht an #

Das sind keine Prüfungs-Ablehnungen — der Upload schlägt schlicht fehl oder der Slot bleibt rot. Drei Ursachen decken fast alle Fälle ab:

Falsche Pixelmaße #

Jeder Geräte-Slot akzeptiert nur exakte Größen. Ein 1290 × 2796-Bild in einem Slot, der 1320 × 2868 erwartet, scheitert stillschweigend oder mit einem vagen Fehler. Das ist der häufigste Blocker in der Einreichungsnacht — prüfen Sie Ihre Dateien gegen die vollständige Screenshot-Größenreferenz oder ziehen Sie sie in unseren kostenlosen Screenshot-Validator, der Ihnen sofort sagt, in welchen Slot (falls überhaupt) jedes Bild passt.

Falsches Format oder Farbprofil #

Screenshots müssen PNG oder hochwertiges JPEG sein, RGB (Display P3 und sRGB sind beide in Ordnung), keine Alpha-Transparenz in JPEGs, keine CMYK-Exporte aus Design-Tools.

Falsche Anzahl #

Jede Gerätegröße nimmt 1–10 Screenshots pro Sprache. Null in einem erforderlichen Slot blockiert die Einreichung komplett — eine klassische Überraschung, wenn Sie watchOS- oder visionOS-Unterstützung hinzufügen und feststellen, dass diese Plattformen eigene Sets brauchen.

Lösung: in den exakt erforderlichen Größen neu erzeugen. Wenn Sie von Hand aus einem Design-Tool exportieren, verschwindet dieses ganze Tor mit einem Screenshot-Generator, der die exakten Maße jedes Slots aus einem Design exportiert.


Tor 2: App-Review-Ablehnungen, nach Richtlinie #

Richtlinie 2.3.3 — Screenshots zeigen die App nicht im Gebrauch #

Die große. Apples Regel: Screenshots müssen die App im Gebrauch zeigen — nicht nur die Titelgrafik, die Login-Seite oder den Splash-Screen.

Typische Auslöser:

  • Ein Screenshot-Set, das überwiegend aus Logo, Slogan und Marketing-Grafik mit wenig sichtbarer UI besteht
  • Login-/Onboarding-Bildschirme als Ihre primären Screenshots
  • Konzept-Mockups von Funktionen, die nichts mit der ausgelieferten App zu tun haben
  • Screenshots der UI einer anderen Plattform (die Web-App, die Android-Version)

Lösung: das Set um echte Bildschirme herum neu aufbauen. Die gute Nachricht: Das Layout, das die Prüfung besteht — echte UI in einem Geräterahmen mit kurzer Bildunterschrift — ist auch das Layout, das am besten konvertiert. Bildunterschrift-Overlays und Geräterahmen sind ausdrücklich erlaubt; erfundene UI wird beanstandet.

Richtlinie 2.3.1 — Funktionen zeigen, die nicht existieren #

Wenn ein Screenshot eine Funktion demonstriert, die der Prüfer im eingereichten Build nicht findet, rechnen Sie mit einer Ablehnung (und bei Wiederholung mit Schlimmerem). Das passiert oft unabsichtlich: Marketing-Screenshots aus einem Beta-Build mit Funktionen, die gestrichen wurden.

Lösung: jeden Screenshot gegen den Build prüfen, den Sie tatsächlich einreichen. Aktualisieren Sie Bildunterschriften, die etwas versprechen, das die aktuelle Version nicht kann.

Richtlinie 2.3.8 — Metadaten sind nicht für alle Zielgruppen geeignet #

Screenshots und Previews müssen für ein 4+-Publikum geeignet sein, unabhängig von der Altersfreigabe Ihrer App, weil sie für jeden beim Stöbern sichtbar sind. Gewalt, Erwachsenenthemen oder Kraftausdrücke, die innerhalb einer 17+-App in Ordnung sind, sind es auf deren Produktseite nicht.

Lösung: zahmere Bildschirme wählen oder den problematischen Inhalt zuschneiden/verwischen. Spiele mit reifen Themen bestehen meist mit Atmosphäre-Aufnahmen statt expliziter Gameplay-Momente.

Richtlinie 2.3.10 — Verweise auf andere Plattformen #

Screenshots mit Android-Geräterahmen, Google-Play-Badges oder „auch auf Android!"-Bildunterschriften werden abgelehnt. Das trifft Teams, die ein Marketing-Bilderset über beide Stores hinweg wiederverwenden.

Lösung: Assets pro Store getrennt halten. Wenn Sie beide Listings pflegen, macht ein Werkzeug, das App-Store- und Google-Play-Sets nebeneinander verwaltet, ein Vermischen schwer.

Richtlinie 5.2 / 2.3.7 — fremdes geistiges Eigentum #

Logos Dritter, Promi-Fotos, Namen von Konkurrenz-Apps, markenrechtlich geschützte Charaktere oder Produktaufnahmen eines anderen Entwicklers in Ihren Screenshots laden sowohl eine Ablehnung als auch möglicherweise einen Rechtsstreit ein.

Lösung: nur Inhalte zeigen, an denen Sie die Rechte haben. Ersetzen Sie echte Drittinhalte, die in Ihrer UI sichtbar sind (Albumcover, Videos, Marken-Feeds), vor der Aufnahme durch lizenzierte oder generische Platzhalter.

Platzhalter und lieblose Inhalte #

„Lorem ipsum", „Test test", leere Zustände ohne Daten oder offensichtlich kaputte Layouts wirken wie eine unfertige App. Prüfer beurteilen die Sorgfalt der ganzen Einreichung teils an den Screenshots.

Lösung: mit realistischen Demo-Daten aufnehmen — volle Listen, plausible Namen, glaubwürdige Zahlen. (Realistisch, nicht echt: Verwenden Sie niemals echte Nutzerdaten in einem Screenshot.)

Veraltende Aussagen: Preise, Aktionen, Rankings #

„Diese Woche 50 % Rabatt", „Produktivitäts-App Nr. 1" oder ein in einer Bildunterschrift gedruckter Preis wird ungenau, sobald sich etwas ändert — und Prüfer wissen das. Zeitlich begrenzte Aussagen werden für Previews ausdrücklich abgeraten und sind in Screenshots riskant.

Lösung: Bildunterschriften auf das beziehen, was die App tut. Aktionen in den Werbetext setzen (den Sie jederzeit ohne Prüfung bearbeiten können).


Schnell zurück zu „Genehmigt" #

Eine Screenshot-Ablehnung erfordert keinen neuen Build:

  1. Lesen Sie die Nachricht im Resolution Center genau — sie nennt die Richtlinie und hängt meist den beanstandeten Screenshot an.
  2. Ersetzen Sie die markierten Bilder in App Store Connect in derselben Version. Medien- und Metadaten-Änderungen an einer abgelehnten Version brauchen kein neues Binary.
  3. Antworten Sie im Resolution Center mit dem, was Sie geändert haben, und reichen Sie erneut ein. Reine Metadaten-Neuprüfungen gehen typischerweise schnell.
  4. Wenn Sie die Ablehnung für falsch halten, können Sie Einspruch einlegen — aber bei Screenshots ist das Ersetzen des Assets fast immer schneller als das Argumentieren.

Ein Prozesshinweis, der überrascht: Außerhalb einer Ablehnung können Screenshots nur durch das Einreichen einer neuen App-Version geändert werden. Wenn Ihr Set eine Richtlinie verletzt, die Prüfer strenger durchzusetzen beginnen, kann es ein sonst triviales Bugfix-Release blockieren — ein weiterer Grund, das Set einmal richtig zu machen.


Die Checkliste vor der Einreichung #

Führen Sie das vor jeder Einreichung mit neuen Screenshots durch:

  • Exakte Pixelmaße für jeden Slot — hier validieren
  • Jeder Screenshot zeigt echte, aktuelle App-UI (2.3.3)
  • Nichts gezeigt, was der Build nicht kann (2.3.1)
  • Für 4+ geeignete Inhalte (2.3.8)
  • Keine Android-/Fremdplattform-Rahmen, -Badges oder -Erwähnungen (2.3.10)
  • Keine fremden Marken, Logos oder Personen ohne Rechte (5.2)
  • Realistische Demo-Daten, keine Platzhalter
  • Keine Preise, Rabatte oder Ranking-Aussagen in die Bilder eingebrannt
  • Alle erforderlichen Gerätegrößen abgedeckt, einschließlich Watch/Vision Pro, falls Sie dort veröffentlichen
  • Für Preview-Videos die separate Video-Spezifikation prüfen

Die offiziellen Texte finden sich in Apples App-Review-Richtlinien, Abschnitt 2.3 und den Screenshot-Spezifikationen.


Machen Sie die ganze Kategorie der Ablehnung unmöglich #

Die Hälfte dieser Liste — Maße, Abdeckung, Konsistenz pro Sprache — ist mechanisch, und für mechanische Probleme sind Werkzeuge da. Screenshot Studio nimmt Ihre echte UI in aktuellen Geräterahmen auf (von Natur aus 2.3.3-freundlich), exportiert jede erforderliche Größe exakt (keine Maß-Ablehnungen), hält lokalisierte Sets synchron und lädt zu App Store Connect hoch, mit jeder Datei im richtigen Slot.

Die Ermessensentscheidungen — was zeigen, was behaupten — bleiben Ihre. Die Ablehnungen aus der Dateimechanik müssen es nicht.

Laden Sie Screenshot Studio kostenlos herunter und reichen Sie Ihr nächstes Update ein, ohne die Luft anzuhalten.

Ressourcen für Entwickler

Schließen Sie sich anderen Entwicklern an und sparen Sie Zeit

Keine Designkenntnisse. Kein Figma-Export-Aufwand. Keine manuellen Uploads.