So erstellst du App-Store-Screenshots für eine React-Native-App (2026)

Das sagt dir niemand, wenn du deine erste React-Native-App im App Store veröffentlichst: Es gibt keinen eingebauten Weg, die Screenshots zu erzeugen, die der Store verlangt. Native iOS-Entwickler greifen zu Xcodes UI-Test-Recorder; native Android-Entwickler haben Espresso fest im Build verankert. React Native sitzt auf beiden auf, wobei deine eigentliche App-Logik in JavaScript läuft — und keines dieser Tools weiß, dass dein JS existiert. Du musst die Lücke selbst schließen.

Dieser Beitrag führt durch die Ansätze, die in der Ära der New Architecture tatsächlich funktionieren (RN 0.7x und höher, 2026), mit konkreten Befehlen. Er ist ehrlich über die Kosten, denn jede dieser Optionen hat echte Kosten. Danach behandelt er den Teil, der nach der Aufnahme kommt — die Marketing-Komposition und Lokalisierung —, der unabhängig davon, wie du die Quell-Frames einfängst, ein wirklich eigenständiges Problem ist.

Das eigentliche Problem: keine First-Party-Pipeline

App Store Connect will Screenshots in exakten Pixel-Abmessungen, idealerweise ein Set pro Geräteklasse und ein Set pro unterstützter Locale. Google Play will seine eigenen Größen. Ein natives iOS-Projekt kann den Simulator per XCUITest steuern und Frames auswerfen; React Native kann das technisch auch, aber der Test, den du schreibst, läuft gegen die native Shell — das gebündelte Binary — nicht direkt gegen deine JavaScript-Komponenten. Du automatisierst eine Black Box, die zufällig dein JS rendert.

Diese Unterscheidung ist wichtiger, als sie klingt. Sie bedeutet, dass deine Screenshot-Automatisierung aus Gründen bricht, die nichts mit deinem React-Code zu tun haben (ein Metro-Bundler, der nicht lief, ein Simulator, der in einem Berechtigungsdialog hängen bleibt, ein nativer Build, der von deinem JS abgedriftet ist), und sie bedeutet, dass die Lernkurve die Lernkurve zweier nativer Test-Frameworks ist, nicht die deines vertrauten RN-Stacks. Es gibt drei ernstzunehmende Wege durch dieses Problem. Wähle danach, wie oft du auslieferst.

Option 1 — Fastlane snapshot (iOS) und screengrab (Android)

Fastlane ist das kanonische Open-Source-Automatisierungs-Framework für Mobile, und seine Screenshot-Module sind die kampferprobteste Option. Sie sind auch der größte Aufwand bei der Einrichtung für React Native, weil sie für native Projekte gebaut wurden und RN nur tolerieren.

iOS, über snapshot. Du fügst in Xcode ein UI-Testing-Target hinzu und schreibst XCUITest-Fälle in Swift, die die App zu jedem Screen steuern, den du aufnehmen willst. fastlane snapshot init legt ein Snapfile und eine SnapshotHelper.swift in deinen fastlane/-Ordner. In deinem Test rufst du setupSnapshot(app) auf, startest die App und dann bei jedem Zustand snapshot("01_home"). Du führst es vom Terminal aus mit fastlane snapshot aus — nicht aus Xcode heraus, das liefert keine korrekte Ausgabe. Es durchläuft jeden Simulator und jede Locale in deinem Snapfile und schreibt PNGs nach fastlane/screenshots/.

Die React-Native-Eigenheit: snapshot startet die kompilierte App, die im Debug-Modus bereits einen laufenden Metro-Bundler braucht. Dein Fastfile (oder ein Wrapper-Skript) muss also zuerst Metro starten — der gängige Trick ist, npx react-native start in einer Hintergrund-tmux-Session zu starten, bevor snapshot aufgerufen wird, und sie danach wieder zu beenden. Release-Builds mit eingebettetem JS-Bundle umgehen das, kosten dich aber einen vollständigen Release-Build pro Durchlauf.

Android, über screengrab. Ein komplett anderes Framework: screengrab nutzt Espresso. Du fügst Screengrab.screenshot("name")-Aufrufe in JUnit-Instrumentierungstests ein, deklarierst Berechtigungen (DISABLE_KEYGUARD, WAKE_LOCK, CHANGE_CONFIGURATION und Storage-Berechtigungen), baust eine Debug-APK und eine Test-APK mit ./gradlew assembleDebug assembleAndroidTest und führst fastlane screengrab aus. Die Ausgabe landet in fastlane/metadata/android/. Wie bei iOS müssen Metro und der Emulator bereits laufen — screengrab startet sie nicht für dich.

Stärken:

• CI-integriert und abdriftsicher. Bind es in deine Pipeline ein, und Screenshots werden bei jedem Release-Build neu generiert und stimmen immer mit der ausgelieferten App überein.
• Echtes Rendering pro Locale. Jede Locale läuft im Simulator/Emulator mit ihren echten Locale-Einstellungen, sodass Daten, Zahlen und Währung nativ gerendert werden — nicht in einem Design-Tool vorgetäuscht.
• Kostenlos, Open Source, ausgereift. Kein Abo, riesige Community, gut erforschte Fehlerarten.

Schwächen (sei hier ehrlich mit dir selbst):

• Du pflegst zwei native Test-Suites. XCUITest in Swift für iOS, Espresso/JUnit in Kotlin/Java für Android — als RN-Entwickler können das zwei unvertraute Stacks sein.
• Er testet die native Shell, nicht deine JS-Logik. Die Tests prüfen gerenderte native Views; sie kennen deinen Komponentenbaum nicht.
• Die Einrichtung dauert beim ersten Mal ein bis zwei Tage, und das Metro-Bundler-Tänzchen ist eine wiederkehrende Quelle instabiler CI-Läufe.
• Die Ausgabe besteht aus rohen Frames. Keine Untertitel, keine Geräterahmen, keine Farbverläufe, kein Karussell — nur die nackte App-UI in Simulator-Auflösung.
• Mac für iOS erforderlich. Der Simulator braucht Xcode.

Für einen tieferen Vergleich speziell zur Kompositionsfrage siehe Fastlane snapshot vs. no-code App-Store-Screenshots und den Vergleich Mokbi vs. Fastlane.

Option 2 — Detox-Screenshots (gebaut für React Native)

Detox ist ein Gray-Box-End-to-End-Testing-Framework, das speziell für React Native gemacht wurde, vom Team bei Wix. Wenn du Detox bereits für E2E-Tests einsetzt, sind Screenshots nahezu kostenlos, und die Lernkurve ist ohnehin die, die du erklimmen willst — es ist eine JavaScript-API, kein Swift oder Kotlin.

Der Aufnahme-Befehl ist ein Einzeiler in jedem Test:

// full screen
const path = await device.takeScreenshot('01_home');

// a single element
await element(by.id('paywallRoot')).takeScreenshot('paywall');

Ob diese Bilder als Artefakte erhalten bleiben, steuert das --take-screenshots-Flag (none, failing, manual oder all), konfiguriert in .detoxrc.js. Im manual- oder all-Modus schreiben bestandene Tests nach <artifacts-location>/✓ [test name]/[name].png. Du steuerst die App mit denselben Detox-Matchern, die du auch für Assertions nutzen würdest, zu jedem Zustand und machst dann den Snapshot.

Stärken:

• Es ist eine JS-API. Du schreibst Tests in der Sprache, in der deine App geschrieben ist — keine zweite native Test-Suite in einer Fremdsprache, die du pflegen musst.
• Gray-Box, also versteht es RN. Detox synchronisiert sich mit der Bridge/JSI der App und wartet, bis sie im Ruhezustand ist, was Screenshots deutlich weniger instabil macht als blind getimte XCUITest-Wartezeiten.
• Ein Framework, beide Plattformen. Dieselbe Testdatei nimmt iOS und Android auf.
• Du hast es wahrscheinlich schon, wenn du E2E-Tests machst — dann ist der Grenzaufwand für Screenshots winzig.

Schwächen:

• Detox von Grund auf aufzusetzen ist nicht trivial — native Build-Konfiguration, ein dedizierter Test-Build und Emulator-/Simulator-Setup. Wenn du es nicht bereits einsetzt, ist das eine echte Investition.
• Die Locale-Verwaltung liegt bei dir. Detox fegt nicht automatisch jede App-Store-Locale durch, wie es Snapshots Snapfile tut; du skriptest die Locale-Wechsel selbst oder startest mit anderen Einstellungen neu.
• Die Ausgabe besteht weiterhin aus rohen Frames. Genau wie bei Fastlane — nackte App-UI, keine Marketing-Ebene.
• Screenshots können sich zwischen Host-Rechnern unterscheiden (ein bekanntes Detox-Problem), was wichtig ist, wenn du sie in CI vergleichst, aber für Store-Assets unbedenklich ist.

Option 3 — Manuelle Aufnahme (am einfachsten, und unterschätzt)

Öffne den iOS-Simulator oder einen Android-Emulator, steuere deine eigene App von Hand zu jedem Screen und nimm den Frame auf. Auf iOS speichert Cmd-S im Simulator ein korrekt dimensioniertes PNG auf dem Desktop; xcrun simctl io booted screenshot home.png macht dasselbe vom Terminal aus und lässt sich locker skripten. Auf Android nimmt der Kamera-Button des Emulators oder adb exec-out screencap -p > home.png den Screen auf. Ein physisches Gerät funktioniert auch — aufnehmen und dann per AirDrop übertragen oder anderweitig transferieren.

Das wird zu schnell abgetan. Es hat null Einrichtung, bricht nie in CI, weil es kein CI gibt, und für eine App, die ein paarmal im Jahr ausgeliefert wird, ist es wirklich der schnellste Weg zu einem Satz Quell-Frames. Der Nachteil ist offensichtlich und real: Es ist manuell, regeneriert sich also nicht von selbst, und wenn du einen Screen änderst, werden deine Aufnahmen veraltet, bis du sie neu machst. Für ein Fünf-Screen-Karussell sind das zehn Minuten Arbeit pro Release — günstiger, als eine Testautomatisierung zu pflegen, die du zweimal im Jahr ausführst.

Der Teil, den alle vergessen: Komposition und Lokalisierung

Das eint alle drei Optionen: Jede von ihnen produziert rohe App-Screenshots, und rohe App-Screenshots konvertieren im Store nicht. Das App-Store-Karussell, das tatsächlich Installs bringt, hat einen Geräterahmen um den Screen, einen einzeiligen Untertitel darüber, der den Nutzen erklärt, einen Hintergrund, der nicht das Weiß deiner App ist, und Kontinuität über die fünf Panels hinweg. Keines der obigen Aufnahme-Tools produziert davon irgendetwas — sie hören beim nackten Frame auf. Das ist kein Makel dieser Tools; es ist ein anderer Job.

An dieser Stelle setzt Mokbi an, und es lohnt sich, die Grenze genau zu beschreiben: Es nimmt deine Quell-Screenshots nicht auf — das übernehmen der Simulator, das Gerät oder Fastlane/Detox oben. Was es tut, ist die Marketing-Kompositions- und Lokalisierungs-Ebene, die als Nächstes kommt. Du lädst deine rohen Frames in einen Browser-Editor, umschließt sie mit echten Geräterahmen, fügst Untertitel hinzu, baust mehrteilige Karussells auf, übersetzt die Untertitel dann per Klick in 50 Sprachen und exportierst per Batch in jeder Store-Abmessung. Das Design ist kostenlos mit Vorschau mit Wasserzeichen; unbegrenzter Export und Store-Veröffentlichung sind im Abo enthalten — Solo €29.99/mo (1 App) oder Studio €49.99/mo (bis zu 5 Apps), kein einmaliger Kauf. Der Grund, warum es sauber dazupasst: Es löst das Problem, das deine Aufnahme-Pipeline nicht einmal versucht — einen Ordner voller PNGs in ein lokalisiertes, store-fertiges Karussell zu verwandeln, ohne Photoshop zu öffnen oder manuellem Größenanpassen für 50 Sprachen.

Der realistische kombinierte Workflow

1. Quell-Frames aufnehmen. Wähle eine Option: Fastlane (snapshot + screengrab) auf CI für häufige Releases, Detox, wenn du bereits E2E-Tests fährst, oder manuelle Simulator-Aufnahme für seltene. Ausgabe: ein Ordner mit rohen PNGs pro Screen, pro Gerät.
2. Komponieren, beschriften und einrahmen. Lade die rohen Frames in einen Browser-Editor. Geräterahmen hinzufügen, die Nutzen-Untertitel schreiben, das Fünf-Panel-Karussell bauen, einen Hintergrund wählen.
3. Übersetzen. Übersetze die Untertitel per Klick in 50 Sprachen und prüfe die für dich wichtigsten Sprachen anschließend stichprobenartig von Hand.
4. Batch-Export. Exportiere jede Locale in jeder erforderlichen Abmessung für App Store Connect und Google Play in einem Durchgang.
5. Beim nächsten Release austauschen. Nimm die geänderten Frames neu auf (Fastlane/Detox erneut ausführen oder von Hand aufnehmen), öffne das gespeicherte Projekt erneut, tausche die Screenshots aus, exportiere neu. Die Untertitel- und Übersetzungsarbeit ist bereits erledigt.

Wann du die Automatisierung weglassen kannst

Wenn du ein bis drei Releases im Jahr ausliefert — was die meisten Indie-React-Native-Apps beschreibt —, zahlt sich der Aufwand für Fastlane oder Detox fast nie aus. Du würdest einen Tag mit XCUITest und dem Metro-Bundler-Tänzchen verbringen, um zweimal im Jahr zehn Minuten manuelle Aufnahme zu sparen. Diese Rechnung geht nicht auf. Nimm von Hand im Simulator auf, komponiere und lokalisiere im Browser, und du bist insgesamt schneller fertig, als die Automatisierung einmalig einzurichten dauern würde.

Die Automatisierung zahlt sich aus, wenn du wöchentlich oder täglich ausliefert, wenn Screenshot-Abdriften zu einem wiederkehrenden Bug wird oder wenn du ein Portfolio von Apps betreibst und sich der Aufnahmeaufwand pro App vervielfacht. Bei diesem Umfang ist Fastlane auf CI (oder Detox, wenn es bereits in deinem Stack ist) die richtige Wahl für den Aufnahme-Schritt — und trotzdem kombinierst du es mit einem Browser-Kompositions-Tool für die Marketing-Ebene, denn keine Aufnahme-Pipeline produziert ein fertiges Karussell.

Bevor du irgendetwas exportierst, lohnt es sich, die Zielwerte zu bestätigen: die App-Store-Screenshot-Größen, die du tatsächlich hochladen musst, und die App-Store-Screenshot-Anforderungen, die Einreichungen zum Scheitern bringen. Das einmal richtig zu machen, erspart dir eine Extrarunde mit App Review.

Was du als Nächstes liest

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

Editor öffnen →