Store-Screenshots automatisieren mit fastlane snapshot und frameit

fastlane automatisiert Store-Screenshots in drei Stufen. snapshot (iOS) und screengrab (Android) führen deine UI-Tests auf Simulatoren oder Emulatoren in jeder angegebenen Sprache aus und speichern an jeder markierten Stelle einen Screenshot. frameit legt Geräterahmen, einen Hintergrund und eine Headline darum. deliver und supply laden die Ergebnisse in App Store Connect und Google Play hoch. Ist das einmal eingerichtet, entstehen alle Screenshots mit einem einzigen Befehl neu.

Dieser letzte Satz ist der ganze Reiz, und die Einrichtung ist der ganze Preis. Dieser Leitfaden geht jedes Teil mit funktionierender Konfiguration durch und gibt dann eine ehrliche Einschätzung, wann es sich lohnt.

So funktioniert fastlane snapshot

fastlane snapshot nutzt das UI-Testing von Xcode. Du schreibst einen UI-Test, der durch deine App klickt; an jedem Screen, der sich zu zeigen lohnt, ruft er snapshot("01Home") auf. snapshot führt diesen Test einmal pro Kombination aus Gerät und Sprache aus und sammelt die Bilder in fastlane/screenshots/<language>/.

Einrichtung

1. Füg deinem Xcode-Projekt ein UI-Test-Target hinzu, falls du noch keins hast.
2. Führ fastlane snapshot init im Projektordner aus. Das legt ein Snapfile und eine SnapshotHelper.swift an.
3. Füg SnapshotHelper.swift dem UI-Test-Target hinzu.

Der UI-Test

import XCTest

final class ScreenshotTests: XCTestCase {
    override func setUp() {
        continueAfterFailure = false
        let app = XCUIApplication()
        setupSnapshot(app)
        app.launchArguments += ["-demoData"]
        app.launch()
    }

    func testStoreScreenshots() {
        let app = XCUIApplication()

        snapshot("01Home")

        app.tabBars.buttons["Budget"].tap()
        snapshot("02Budget")

        app.buttons["Add expense"].tap()
        snapshot("03AddExpense")
    }
}

setupSnapshot(app) übergibt die aktuelle Sprache und Region an die App – so erzeugt ein einziger Test alle lokalisierten Sets. Das Argument -demoData ist unsere eigene Konvention: Die App prüft in Debug-Builds darauf und lädt Beispielinhalte, damit kein Screenshot einen leeren Zustand zeigt. Nummern vor den Namen halten die Dateien in der Reihenfolge, in der sie hochgeladen werden.

Das Snapfile

# fastlane/Snapfile
devices([
  "iPhone 17 Pro Max",
  "iPad Pro 13-inch (M5)"
])

languages([
  "en-US",
  "de-DE",
  "ja"
])

scheme("MyAppUITests")
output_directory("./fastlane/screenshots")
clear_previous_screenshots(true)

override_status_bar(true)   # 9:41, full battery, full reception
dark_mode(false)
launch_arguments(["-demoData"])

Die Gerätenamen müssen zu Simulatoren passen, die in deinem Xcode installiert sind; xcrun simctl list devicetypes zeigt sie an. Ein iPhone 17 Pro Max-Simulator nimmt in 1320 × 2868 auf, eine der Größen, die App Store Connect für den größten iPhone-Platz akzeptiert. Dann ausführen:

fastlane snapshot

Weitere snapshot-Optionen, die man kennen sollte: localize_simulator stellt auch die Systemsprache des Simulators um, erase_simulator startet jeden Durchlauf mit einem frischen Gerät, reinstall_app deinstalliert die App vorher, und override_status_bar_arguments nimmt deine eigenen simctl status_bar-Flags. Wenn du wissen willst, was diese Flags tun: Unser Leitfaden zu sauberen Screenshots aus Simulator und Emulator erklärt sie und die manuellen Befehle, die snapshot automatisiert.

screengrab: das Android-Gegenstück

screengrab macht dasselbe mit Android-Instrumentation-Tests. Füg die Library zu deinen Test-Abhängigkeiten hinzu:

// app/build.gradle
androidTestImplementation 'tools.fastlane:screengrab:x.x.x'

Achte darauf, dass src/debug/AndroidManifest.xml die Berechtigungen aus der Doku enthält (etwa DISABLE_KEYGUARD), und schreib dann den Test:

@RunWith(AndroidJUnit4.class)
public class ScreenshotTest {
    @ClassRule
    public static final LocaleTestRule localeTestRule = new LocaleTestRule();

    @BeforeClass
    public static void beforeAll() {
        CleanStatusBar.enableWithDefaults();
    }

    @AfterClass
    public static void afterAll() {
        CleanStatusBar.disable();
    }

    @Rule
    public ActivityScenarioRule<MainActivity> rule =
        new ActivityScenarioRule<>(MainActivity.class);

    @Test
    public void storeScreenshots() {
        Screengrab.screenshot("01_home");
        onView(withId(R.id.nav_budget)).perform(click());
        Screengrab.screenshot("02_budget");
    }
}

LocaleTestRule wechselt für jeden Durchlauf die Sprache, und CleanStatusBar ist ein Wrapper um den Demo-Modus der Android-System-UI; laut Doku braucht er API-Level 23 oder höher. Bau die APKs, erzeug ein Screengrabfile und führ es aus:

./gradlew assembleDebug assembleAndroidTest
fastlane screengrab init     # creates the Screengrabfile
fastlane screengrab

# fastlane/Screengrabfile
app_package_name("com.example.app")
app_apk_path("app/build/outputs/apk/debug/app-debug.apk")
tests_apk_path("app/build/outputs/apk/androidTest/debug/app-debug-androidTest.apk")
locales(["en-US", "de-DE", "ja-JP"])
clear_previous_screenshots(true)

Die Screenshots landen standardmäßig in fastlane/metadata/android/<locale>/images/phoneScreenshots, also genau dort, wo supply sie sucht. Eine Sache solltest du auf Android prüfen: Google Play lehnt Screenshots ab, deren lange Seite mehr als doppelt so lang ist wie die kurze. Wähl also ein Emulator-Profil, das nicht höher als 2:1 ist.

frameit: Geräterahmen und Headlines

frameit nimmt die rohen Aufnahmen und setzt sie in Geräterahmen. Es braucht ImageMagick (brew install imagemagick). Die Rahmen werden beim ersten Aufruf automatisch heruntergeladen.

fastlane frameit            # iOS and Mac screenshots
fastlane frameit android    # Android screenshots
fastlane frameit silver     # silver frame variants

Ein Geräterahmen allein macht einen Screenshot noch nicht App Store-tauglich: Das gerahmte Bild passt womöglich zu keiner Größe, die App Store Connect akzeptiert. Laut fastlane-Doku brauchst du für App Store-Uploads eine Framefile.json mit Titeln und einem Hintergrund – das erzeugt stattdessen ein vollständiges Marketingbild.

Framefile.json

Leg sie in den Ordner screenshots:

{
  "device_frame_version": "latest",
  "default": {
    "title": {
      "font": "./fonts/Inter-Bold.ttf",
      "font_size": 110,
      "color": "#0F172A"
    },
    "keyword": {
      "font": "./fonts/Inter-Bold.ttf",
      "color": "#F97316"
    },
    "background": "./background.jpg",
    "padding": 50,
    "show_complete_frame": false,
    "title_below_image": false
  },
  "data": [
    { "filter": "01Home" },
    { "filter": "02Budget", "keyword": { "color": "#3B82F6" } },
    { "filter": "03AddExpense" }
  ]
}

Jeder Eintrag in data greift für Screenshots, deren Dateiname seinen filter enthält, und kann die Standardwerte überschreiben. Der eigentliche Text steht in Dateien pro Sprache, title.strings und optional keyword.strings, jeweils im Ordner der Sprache:

"01Home" = "See every euro, every month";
"02Budget" = "Budgets that adjust themselves";
"03AddExpense" = "Log a purchase in two taps";

Die leere erste Zeile ist Absicht: Laut Doku muss die Datei mit einer beginnen und in UTF-8 oder UTF-16 BE mit BOM gespeichert sein. Außerdem steht dort, dass du einen Hintergrund angeben musst, wenn du Titel willst. Wenn keine Titel erscheinen, prüf zuerst diese drei Punkte.

Die Geräterahmen von frameit hinken neuer Hardware hinterher

Die Rahmen von frameit kommen aus dem separaten Repository frameit-frames, und neue Rahmen kommen erst nach dem Erscheinen der Geräte dazu. Als wir im Oktober 2026 nachgesehen haben:

In der Praxis heißt das: Wenn du auf dem neuesten Simulator aufnimmst, gibt es dafür vielleicht keinen Rahmen. Deine Optionen sind, auf einem Gerät aufzunehmen, für das es einen Rahmen gibt (und hinzunehmen, dass seine Bildschirmgröße womöglich nicht zum gewünschten Store-Platz passt), einen Gerätetyp mit force_device_type zu erzwingen oder auf Rahmen zu verzichten und ein randloses Layout zu nehmen.

Hochladen mit deliver und supply

# iOS: upload only screenshots, replacing what's there
fastlane deliver --skip_binary_upload --skip_metadata --overwrite_screenshots

# Android: upload only images and screenshots
fastlane supply --skip_upload_apk --skip_upload_aab \
  --skip_upload_metadata --skip_upload_changelogs

deliver liest fastlane/screenshots mit einem Unterordner pro Sprache und erkennt den Gerätetyp an der Auflösung jedes Bildes – jede Datei muss also vor dem Upload eine akzeptierte Größe haben. supply liest fastlane/metadata/android/<locale>/images/ mit den Ordnern phoneScreenshots, sevenInchScreenshots und tenInchScreenshots. Zu einer Lane verkettet, ist der Weg von der Aufnahme bis zum Upload ein einziger Befehl:

lane :screenshots do
  snapshot
  frameit(white: true)
  deliver(skip_binary_upload: true, skip_metadata: true,
          overwrite_screenshots: true)
end

Wenn du fastlane nicht nutzt, dir den manuellen Upload aber trotzdem sparen willst, haben wir darüber geschrieben, wie du direkt in die App Stores hochlädst, aus einem Designtool heraus.

Praktische Stolpersteine, mit denen du rechnen solltest

Keiner davon ist ein Grund, auf fastlane zu verzichten, aber jeder kostet dich in der ersten Woche Zeit, wenn du nicht damit rechnest.

Screenshot-Tests sind langsam, also halt sie getrennt

Ein Durchlauf ist ungefähr: jeder Screen mal jedes Gerät mal jede Sprache. Drei Geräte und zehn Sprachen sind dreißig Durchläufe deines Tests. Pack die Screenshot-Tests in ein eigenes Scheme oder einen eigenen Testplan, damit sie nicht mit jedem Unit-Test laufen, und starte sie auf Release-Branches oder von Hand statt bei jedem Commit.

Auf Inhalte warten, nicht auf Zeit

Ein häufiger Grund für einen schlechten Screenshot ist, einen Moment zu früh aufzunehmen: ein Spinner, ein halb geladenes Bild, eine Liste, die noch reinanimiert. Warte in UI-Tests darauf, dass ein bestimmtes Element existiert (waitForExistence(timeout:) auf iOS, eine Espresso-Idling-Resource oder ein UI-Automator-Wait auf Android), bevor du snapshot aufrufst. Feste Sleeps funktionieren auf deinem Rechner und scheitern auf einem langsameren CI-Runner.

Mach die Demodaten deterministisch

Wenn der Screenshot Datumsangaben zeigt, ändert sich „vor 3 Tagen“ jeden Tag, und Summen verschieben sich, wenn sich die Fixtures ändern. Fixier die Uhrzeit in deinem Demodaten-Modus, nutz feste Fixtures, und die Screenshots ändern sich nur, wenn sich die UI ändert. Dadurch lässt sich der Output im Review auch diffen – einer der echten Vorteile, wenn Screenshots in der Versionsverwaltung liegen.

Übersetzte UI ist nur die Hälfte eines lokalisierten Screenshots

snapshot liefert dir die UI der App in jeder Sprache gratis. Die Headlines in title.strings musst du trotzdem für jede Sprache schreiben, und eine wörtliche Übersetzung einer knackigen englischen Headline ist oft nicht mehr knackig. Unser Leitfaden zum Lokalisieren von App-Store-Screenshots zeigt, was du über die Wörter hinaus anpassen solltest.

CI braucht einen Mac mit den richtigen Simulatoren

snapshot läuft auf macOS mit Xcode, CI heißt also ein macOS-Runner, auf dem die Simulator-Runtimes installiert sind, die dein Snapfile nennt. Die Gerätenamen im Snapfile müssen zu Simulatoren passen, die es auf diesem Runner gibt. Pinne also die Xcode-Version deiner CI und aktualisier das Snapfile, wenn du auf eine neue wechselst.

Wann sich Automatisierung lohnt und wann nicht

Wir bauen selbst ein Designtool, also nimm unsere Einschätzung mit diesem Wissen. Aber für manche Teams ist fastlane wirklich die richtige Antwort.

Automatisierung lohnt sich meistens, wenn:

• du alle paar Wochen veröffentlichst und sich die UI auf deinen Screenshots zwischen den Releases ändert.
• du in vielen Sprachen veröffentlichst, wo sich jede Aufnahme mit der Zahl der Sprachen multipliziert.
• du schon UI-Tests hast oder sowieso welche willst.
• sich jemand im Team wohl damit fühlt, eine Ruby- und ImageMagick-Toolchain in der CI zu betreuen.

Eher nicht, wenn:

• du in ein oder zwei Sprachen veröffentlichst und die Screenshots ein paar Mal im Jahr aktualisierst.
• die Screenshots ein Designproblem sind: eigene Layouts, Illustrationen, ein Panorama-Set.
• deine Screens einen Zustand brauchen, der aus einem UI-Test schwer zu erreichen ist (Zahlungen, Live-Daten, andere Nutzer).

Viele Teams machen beides: snapshot für saubere, lokalisierte Aufnahmen und ein Designtool für die Marketing-Ebene obendrauf. Unser Vergleich Launch Shots vs. fastlane frameit zeigt das im Detail, und wenn du ein Designtool in Betracht ziehst, zeigt unser Leitfaden zum Erstellen von App-Store-Screenshots in Figma die manuelle Alternative. Launch Shots gehört zur zweiten Gruppe: Du bringst die Aufnahmen mit (auch welche aus snapshot), und es kümmert sich um Layout, Übersetzung und Upload.

Kurz gesagt

• iOS: UI-Test-Target, fastlane snapshot init, setupSnapshot(app), snapshot("01Home"), ein Snapfile mit Geräten, Sprachen und override_status_bar(true).
• Android: tools.fastlane:screengrab, LocaleTestRule, CleanStatusBar, Screengrab.screenshot(), ein Screengrabfile.
• frameit: ImageMagick, Framefile.json mit Hintergrund, title.strings pro Sprache, beginnend mit einer leeren Zeile.
• Prüf, ob das Rahmen-Repository dein Aufnahmegerät hat, bevor du dich darauf verlässt.
• deliver und supply laden hoch; prüf vorher, ob jede Datei eine akzeptierte Größe hat. Unsere Übersicht der Screenshot-Größen und die ASO-Checkliste für den Launch helfen beim Rest des Store-Eintrags.