LaunchLint Academy
Die kurze Antwort
- App-Store-Screenshots sind zugleich technisches Upload-Artefakt und wichtigste visuelle Verkaufsfläche. Gute Motive müssen deshalb die aktuellen Größenregeln erfüllen, echte Produktoberflächen zeigen und bereits in der ersten Sequenz ein klares Nutzenversprechen vermitteln.
- Dieser Leitfaden trennt Pflichtformat, Geräteabdeckung und kreative Gestaltung. Er zeigt außerdem einen wiederholbaren Workflow für Expo- und React-Native-Teams, mit dem sich eine konsistente Galerie vor jedem Release prüfen lässt.
Was Apple tatsächlich verlangt
Apple erlaubt pro unterstützter Gerätegröße zwischen einem und zehn Screenshots. Die Dateien müssen als JPEG, JPG oder PNG vorliegen; Transparenz ist nicht zulässig. App-Vorschauen sind optional, Screenshots für die erforderlichen Geräteklassen dagegen Teil der Produktseite.
Die Spezifikation unterscheidet iPhone- und iPad-Displaygrößen. Läuft deine App auf dem iPad, brauchst du passende iPad-Motive. Verlasse dich nicht darauf, dass eine einzelne Smartphone-Serie jede Zielklasse automatisch und überzeugend abdeckt.
Technischer Mindestcheck
- Ein bis zehn Screenshots je erforderlicher Gerätegröße
- JPEG, JPG oder PNG ohne Alphakanal
- Nur zulässige Pixelmaße aus App Store Connect
- Eigene Motive für iPad, wenn die App dort läuft
- Status und Fehlermeldungen direkt nach dem Upload prüfen
Pixelgrößen und Geräteklassen planen
Für aktuelle große iPhones akzeptiert Apple mehrere exakte Hoch- und Querformatgrößen, darunter 1260 × 2736, 1290 × 2796 und 1320 × 2868 Pixel. Für 13-Zoll-iPads gehören 2064 × 2752 oder 2048 × 2732 Pixel zu den zulässigen Hochformaten. Entscheidend ist immer die aktuelle Tabelle in der Apple-Dokumentation.
Baue deine Vorlagen nicht um einen Gerätenamen, sondern um eine belegte Zielauflösung. So bleiben Export, Benennung und QA stabil, auch wenn Apple neue Geräte einführt oder App Store Connect eine andere Displayklasse als Primärslot verwendet.
Saubere Größenmatrix
- Zielgeräte und unterstützte Plattformen aus dem Build notieren
- Zulässige Pixelmaße mit Datum dokumentieren
- Master-Canvas pro Seitenverhältnis anlegen
- Exports automatisch auf Breite und Höhe prüfen
- Vor dem Release die offizielle Spezifikation erneut öffnen
Echte App statt erfundener Oberfläche
Ein Screenshot sollte die tatsächliche Nutzung deiner App repräsentieren. Dekorative Hintergründe, kurze Überschriften und Geräte-Rahmen können die Aussage unterstützen, dürfen aber keine Funktion versprechen, die im eingereichten Build fehlt oder anders funktioniert.
Für KI-erstellte Apps ist diese Kontrolle besonders wichtig: Prototyp-Mockups, alte Komponenten und nicht mehr aktive Paywalls landen schnell im Designordner. Leite jedes Motiv aus einem reproduzierbaren App-Zustand ab und verknüpfe es mit der getesteten Build-Version.
Belegbare Motive
- Jedes Motiv einer realen Route oder Funktion zuordnen
- Keine geplanten Funktionen als bereits verfügbar darstellen
- Beispieldaten deutlich und plausibel halten
- Systemdialoge und Berechtigungen nicht irreführend nachbauen
- Buildnummer und Aufnahmedatum intern festhalten
Die Galerie als kurze Produktgeschichte
Die ersten drei Motive tragen meist den größten Teil der Botschaft. Beginne mit dem Kernnutzen, zeige danach den wichtigsten Arbeitsablauf und belege schließlich ein Ergebnis. Eine chronologische Tour durch jede Navigation ist selten so verständlich wie eine problemorientierte Sequenz.
Jede Karte braucht genau eine Aussage. Kurze, konkrete Headlines sind schneller erfassbar als Feature-Listen. Wenn ein Nutzer erst kleine UI-Texte lesen muss, um den Unterschied zwischen zwei Screens zu verstehen, ist die visuelle Hierarchie noch nicht stark genug.
Empfohlene Dramaturgie
- Motiv 1: größtes Ergebnis oder Kernnutzen
- Motiv 2: zentraler Workflow
- Motiv 3: glaubwürdiger Beleg oder Ergebnisansicht
- Weitere Motive: Differenzierung, Integrationen und Vertrauen
- Letztes Motiv: sinnvoller Abschluss statt leerer Wiederholung
Lokalisierung ohne Layoutbruch
Screenshots lassen sich in App Store Connect lokalisieren. Das lohnt sich nur, wenn nicht bloß die Überschrift übersetzt wird, während die sichtbare App weiterhin eine andere Sprache zeigt. Text, Datumsformat, Währung und Beispielinhalte müssen zusammenpassen.
Plane längere deutsche, französische oder italienische Formulierungen bereits im Master-Layout ein. Übersetzungen dürfen nicht auf unlesbare Schriftgrößen schrumpfen. Besser sind flexible Textzonen, feste Zeilenlimits und eine sprachspezifische redaktionelle Kürzung.
Lokalisierungs-QA
- Overlay und sichtbare App-Oberfläche in derselben Sprache
- Währungen, Datum und Zahlenformat regional korrekt
- Keine abgeschnittenen Wörter oder verdeckten UI-Elemente
- Altstände aus anderen Sprachen aus dem Export entfernen
- Jede Locale separat in App Store Connect kontrollieren
Ein reproduzierbarer Aufnahme-Workflow
Definiere vor der Aufnahme feste Testkonten, Beispieldaten, Geräteeinstellungen und App-Zustände. Einheitliche Uhrzeit, Statusleiste und Farbschema verhindern, dass die Galerie wie eine Sammlung zufälliger Einzelbilder wirkt. Sensible Benachrichtigungen und persönliche Daten gehören nie in den Aufnahmeprozess.
Automatisierung kann Screens erfassen und Maße validieren, ersetzt aber nicht die redaktionelle Auswahl. Speichere Rohaufnahme, bearbeitete Vorlage und finalen Export getrennt. Dann lassen sich Texte ändern, ohne den gesamten Zustand der App erneut rekonstruieren zu müssen.
Produktionsablauf
- Shot-Liste mit Route, Zustand und Aussage anlegen
- Saubere Fixture-Daten und dediziertes Testkonto nutzen
- Rohbilder ohne persönliche Daten aufnehmen
- Master-Datei versionskontrolliert oder zentral ablegen
- Finale Exports mit Prüfsumme und Locale kennzeichnen
Visuelle und technische Abnahme
Prüfe nicht nur die einzelne Grafik in voller Auflösung, sondern die gesamte Reihenfolge in einer Vorschau. Kontrast, Schriftgröße und Motivwechsel müssen auch als kleine Store-Karten funktionieren. Wiederholte Screens und uneinheitliche Rahmen schwächen den professionellen Eindruck.
Die technische Abnahme sollte Maße, Dateityp, Alphakanal, Dateigröße und Orientierung maschinell kontrollieren. Danach folgt ein menschlicher Vergleich mit dem Release-Build. Erst beide Prüfungen zusammen decken typische Upload- und Inhaltsfehler ab.
Finale Abnahme
- Alle Dateien besitzen exakt zulässige Maße
- Keine Transparenz, leeren Ränder oder falsche Orientierung
- Text bleibt in kleiner Vorschau lesbar
- Reihenfolge ergibt ohne Zusatzwissen eine Geschichte
- Gezeigte Funktionen stimmen mit dem Release-Build überein
Upload, Review und Pflege nach dem Release
Lade Motive früh genug in App Store Connect, damit Formatfehler nicht erst kurz vor der Einreichung sichtbar werden. Kontrolliere jede Lokalisierung und jedes Gerät im finalen Produktseitenzustand; ein erfolgreicher Datei-Upload ist noch keine inhaltliche Freigabe.
Nach größeren UI-Änderungen gehören Screenshots in die Release-Definition-of-Done. Eine kleine Content-Matrix mit Motiv, Route, Locale, Zielgröße und letztem Prüfdatum macht veraltete Galerien sichtbar, bevor Nutzer oder Prüfer den Widerspruch entdecken.
Release-Gate
- Alle Ziel-Lokalisierungen vollständig hochgeladen
- Vorschau in App Store Connect je Geräteklasse geprüft
- Keine Warnung oder ausstehende Verarbeitung übersehen
- Screenshot-Matrix mit aktueller Buildnummer aktualisiert
- Owner für die Pflege nach UI-Änderungen benannt
Häufige Fragen
Wie viele Screenshots erlaubt Apple?
Für jede unterstützte Gerätegröße kannst du nach aktueller Apple-Dokumentation zwischen einem und zehn Screenshots hochladen.
Muss ich jede iPhone-Größe separat liefern?
Nicht zwingend jede Hardwaregröße. Du musst die von App Store Connect geforderten Displayklassen mit zulässigen Pixelmaßen abdecken und die aktuelle Spezifikation prüfen.
Brauche ich iPad-Screenshots?
Wenn dein Build auf dem iPad läuft, sind passende iPad-Screenshots für die erforderliche Displayklasse nötig.
Darf ich Text und Geräte-Rahmen ergänzen?
Ja, solange die Darstellung wahrheitsgemäß bleibt, die echte App klar repräsentiert und keine nicht vorhandene Funktion suggeriert.
Kann ich dieselben Motive für alle Sprachen verwenden?
Das ist technisch teilweise möglich, aber für eine glaubwürdige lokalisierte Produktseite sollten Overlay, sichtbare UI und regionale Formate zusammenpassen.