Expo App-Store-Screenshots: Warum EAS Submit sie überspringt und wie du sie schnell auslieferst (2026)

Wenn du eine Expo-App auslieferst, endet dein Release-Weg wahrscheinlich in einer Zeile: eas submit. Der Befehl nimmt den von EAS erstellten Build und übergibt ihn an Apple oder Google. Sauber, langweilig, zuverlässig. Dann öffnest du App Store Connect, um den Build live zu schalten — und die Screenshot-Slots sind leer. Jedes Mal.

Das bringt viele ins Stolpern, weil EAS sich anfühlt, als würde es alles erledigen. Es baut, signiert und übermittelt. Kümmert es sich sicher auch um Screenshots? Nein, und die Dokumentation sagt das klar. Das ist kein Bug und kein fehlendes Feature, an dem du etwas ändern könntest — es liegt schlicht außerhalb des Zwecks von EAS Submit.

Was EAS Submit wirklich macht (und was nicht)

EAS Submit ist ein Binär-Lieferdienst. Er lädt genau eine Sache hoch: dein kompiliertes App-Archiv — ein .ipa für iOS, ein .aab für Android — in die Verarbeitungs-Pipeline des Stores. Die Expo-Dokumentation ist explizit über diese Grenze:

„EAS Submit lädt dein Binary hoch, verwaltet aber keine Store-Listing-Metadaten, Screenshots oder Versionshinweise."

Es gibt ein Schwester-Tool, EAS Metadata, das Teile deines App-Store-Listings automatisieren kann — App-Name, Untertitel, lokalisierte Beschreibungen, Keywords, Support-URLs — aus einer Konfigurationsdatei. Es ist wirklich nützlich und das Einrichten lohnt sich. Lies aber seinen Funktionsumfang genau: Screenshots sind nicht enthalten. EAS Metadata überträgt Text, keine Bilder. Deine Screenshots müssen in beiden Stores von dir selbst erstellt und hochgeladen werden.

Das Expo-Screenshot-Problem zerfällt also in zwei klar getrennte Aufgaben, und es hilft, sie gedanklich auseinanderzuhalten:

1. Aufnehmen — rohe Frames deiner echten App-Screens aus einem Build holen.
2. Komponieren & lokalisieren — diese rohen Frames in die eingerahmten, beschrifteten, mehrsprachigen Marketing-Panels verwandeln, die die Stores tatsächlich anzeigen.

EAS erledigt keines von beidem. Expos eigene Store-Asset-Anleitung verweist dich darauf, Frames selbst aufzunehmen und die Panels in einem Tool wie Figma zu gestalten. Gehen wir beide Aufgaben mit konkreten Befehlen durch.

Job 1: Frames aus einem Dev- oder Preview-Build aufnehmen

Du willst Screenshots der echten App, also muss die App irgendwo laufen, wo du sie aufnehmen kannst. Bei Expo bedeutet das ein Dev-Client oder ein Preview-Build — nicht Expo Go, da Expo Go die Expo-Wrapper-UI anzeigt und deine native Konfiguration abweichen kann. Lokal bauen und starten mit den Standard-Expo-Befehlen:

• npx expo run:ios — erstellt das native iOS-Projekt, kompiliert und startet deine App im iOS-Simulator.
• npx expo run:android — dasselbe für einen Android-Emulator (oder ein verbundenes Gerät).

Mit der App im iOS-Simulator reicht ein einziger Befehl im Mac-Terminal für die Aufnahme:

xcrun simctl io booted screenshot home.png

booted spricht den aktuell laufenden Simulator an und schreibt ein pixelgenaues PNG in dein Arbeitsverzeichnis. Zwei Flags sind für Store-Arbeit relevant: --type=png (der Standard, und was die Stores wollen) und --mask=ignored versus --mask=black — die Maske steuert, ob Notch und abgerundete Ecken ins Bild gerendert werden. Für App-Store-Uploads willst du in der Regel die flachen rechteckigen Pixel, mit dem Geräterahmen dann später in der Komposition, also ist die unmaskierte Aufnahme meist der richtige Ausgangspunkt.

Unter Android nimmst du direkt vom Emulator (oder Gerät) mit adb auf:

adb exec-out screencap -p > home.png

Verwende exec-out, nicht shell screencap. Der einfache Shell-Pfad leitet das PNG über ein Pseudo-Terminal, das das Binary auf manchen Setups beschädigt (du erhältst eine korrupte Datei mit unerwünschten Carriage-Returns); exec-out streamt die Bytes direkt durch und ist die zuverlässige Form. Wenn du mehrere Emulatoren laufen hast, spreche einen gezielt mit adb -s <serial> aus adb devices an.

Das ist das gesamte manuelle Aufnahme-Toolkit: zwei Befehle, einer pro Plattform, keine Abhängigkeiten außer Xcode und dem Android SDK, die du für einen nativen Expo-Build ohnehin brauchst.

Job 1, automatisiert: Maestro oder Detox

Manuell zum richtigen Screen navigieren und diese Befehle ausführen ist für eine Handvoll Aufnahmen in Ordnung. Sobald du acht Screens über zwei Geräteklassen hinweg hast oder Screenshots bei jedem Release neu generieren willst, damit sie nie von der echten UI abweichen, automatisierst du die Aufnahme mit einem End-to-End-Testing-Tool, das die App steuern und Frames aufnehmen kann.

Maestro ist das Tool, auf das Expo selbst in seinen dokumentierten EAS-Workflows-Beispielen zurückgreift. Flows sind einfaches YAML, was die Einstiegshürde niedrig hält. Ein Flow, der zu einem Screen navigiert und ihn aufnimmt, sieht so aus:

appId: com.you.yourapp --- - launchApp - tapOn: "Get started" - assertVisible: "Your dashboard" - takeScreenshot: dashboard

Ausführen mit maestro test flows/home.yaml. Der Befehl takeScreenshot schreibt ein PNG in das Test-Ausgabeverzeichnis (setze MAESTRO_TESTS_DIR auf den Pfad, wo die Assets landen sollen). Dieselben Flows laufen im CI auf EAS Workflows — Expos dokumentiertes Beispiel erstellt eine .apk mit einem e2e-test-Build-Profil und führt dann einen .maestro/-Flow dagegen aus — sodass du die Screenshot-Aufnahme in denselben Job einbinden kannst, der deine E2E-Suite ausführt.

Detox ist die andere bewährte Option, mit einer strafferen, programmatischeren JavaScript-API:

const path = await device.takeScreenshot('dashboard');

Sei hier ehrlich mit dir selbst, was das Detox-mit-Expo-Setup angeht. Detox unterstützt Expo nicht offiziell. In der Praxis funktioniert es, wenn du npx expo prebuild ausführst, um die nativen Projekte zu generieren, und einen Release-ähnlichen Client baust (keinen Dev-Client), damit das JS-Bundle eingebettet ist — dann zeigst du Detox auf dieses Binary. Das sind mehr bewegliche Teile als Maestros YAML, und der Gewinn ist Detox' striktere Synchronisierung und Assertion-API. Wenn du Detox bereits einsetzt, nutze es für die Aufnahme; wenn du gerade wählst und dein Ziel Store-Screenshots sind, ist Maestro der leichtere Weg.

Job 1, manuell: die richtige Wahl für seltene Releases

Automatisierung zahlt sich aus, wenn du häufig auslieferst. Wenn du ein bis drei Releases im Jahr veröffentlichst — was die meisten Indie-Expo-Apps beschreibt — ist das Aufsetzen von Maestro-Flows oder einer Detox-Konfiguration für die Screenshot-Aufnahme Arbeit, die du einmal bezahlst und kaum amortisierst. Bei diesem Rhythmus einfach:

1. Den Build starten mit npx expo run:ios / run:android, mit realistischen Demo-Daten befüllen.
2. Zu jedem Haupt-Screen navigieren — manuell.
3. Jeden aufnehmen mit dem simctl- / adb-Befehl oben.

Zwanzig Minuten Klicken schlägt einen halben Tag Test-Aufbau, den du beim nächsten Release nicht mehr weißt zu pflegen. Manuelle Aufnahme ist keine Schande — die Stores können nicht sehen, wie das PNG entstanden ist.

Job 2: Komposition und Lokalisierung für 50 Sprachen

Hier ist der Teil, den die Aufnahme-Tools bewusst nicht anfassen — und der Teil, nach dem die Stores dich wirklich bewerten. Ein roher simctl-Screenshot zeigt deine App-UI auf weißem Hintergrund. Was in der Suche rankt und auf der Produktseite konvertiert, ist das Marketing-Panel: der Screenshot in einem Geräterahmen, auf einem markentypischen Hintergrund, mit einem einzeiligen Untertitel, der erklärt, warum dieser Screen wichtig ist — meist als mehrteiliges Karussell, das von links nach rechts lesbar ist. Und im App Store sind Screenshots pro Gerätegröße und pro Sprache lokalisiert, sodass ein ernsthafter Launch Dutzende von Varianten erfordert, nicht fünf.

Das ist die abgegrenzte Stelle, in die Mokbi passt — und es lohnt sich, die Grenze genau zu beschreiben. Mokbi nimmt deine App nicht auf — du erstellst die Quell-Frames weiterhin mit den Expo-Befehlen oben. Was es tut: diese Frames nehmen und dir erlauben, im Browser sie in echte Geräterahmen einzufügen, Untertitel und Farbverlauf-Hintergründe hinzuzufügen, mehrteilige Karussells aufzubauen, den Untertitel-Text per Klick in 50 Sprachen zu übersetzen und alle App-Store- und Play-Store-Abmessungen auf einmal per Batch zu exportieren. Das Design ist kostenlos mit Vorschau mit Wasserzeichen; unbegrenzter Export ist im Abo enthalten — Solo €29.99/mo (1 App) oder Studio €49.99/mo (bis zu 5 Apps), kein einmaliger Kauf. Es ersetzt den Figma-Vorlagen-Schritt, auf den Expos Anleitung vage verweist — nicht mehr und nicht weniger.

Der realistische kombinierte Workflow

1. Einen Dev/Preview-Client bauen. npx expo run:ios und npx expo run:android, mit guten Demo-Daten befüllen.
2. Quell-Frames aufnehmen. Manuell via xcrun simctl io booted screenshot und adb exec-out screencap -p, oder automatisiert via Maestro takeScreenshot / Detox device.takeScreenshot — idealerweise auf EAS Workflows, damit sie bei jedem Release neu generiert werden.
3. Marketing-Panels komponieren. Die rohen Frames einrahmen, beschriften und das Karussell zusammenstellen.
4. Lokalisieren und Batch-Export. Untertitel in die Zielsprachen übersetzen, alle erforderlichen Abmessungen für beide Stores exportieren.
5. Listing-Assets hochladen. Screenshots in App Store Connect und die Play Console; bei Bedarf mit EAS Metadata für die Textfelder kombinieren.
6. Binary einreichen. eas submit — der einzige Schritt, den EAS selbst erledigt.
7. Beim nächsten Release: geänderte Screens neu aufnehmen, das gespeicherte Kompositionsprojekt wieder öffnen, Frames austauschen, neu exportieren. Untertitel und Übersetzungen bleiben erhalten.

Wann du die Automatisierung weglassen kannst

Greife zu Maestro oder Detox, wenn Screenshot-Abdriften echte Kosten verursacht: du lieferst wöchentlich aus, deine UI ändert sich ständig, oder du betreust viele Apps und kannst dir veraltete Store-Bilder nicht leisten. In diesen Fällen zahlen sich CI-generierte Frames aus, und die React-Native-Screenshot-Tooling-Geschichte (die Expo erbt) ist die Investition wert.

Für alle anderen — wer einmal pro Quartal veröffentlicht — lass es weg. Manuelle Aufnahme mit zwei Terminal-Befehlen, dann Browser-basierte Komposition und Lokalisierung, bringt dich in einem Nachmittag zu einem polierten, mehrsprachigen Listing — ohne etwas zwischen den Releases pflegen zu müssen. Passe die Tools deinem Release-Rhythmus an, nicht daran, was auf einem CI-Dashboard gut aussieht.

So oder so ist die Binär-Seite gelöst: eas submit kümmert sich darum. Prüfe deine Screenshots vor dem Upload gegen die aktuellen Store-Anforderungen — Apple lehnt ein Listing wegen eines einzelnen falschen Pixels ab — und der Rest des Launches ist reine Gestaltung.

Was du als Nächstes liest

• Für Expo-Entwickler
• App-Store-Screenshots für React Native
• Direktvergleich: Mokbi vs. Fastlane
• App-Store-Screenshot-Größen
• App-Store-Screenshot-Anforderungen

Editor öffnen →