Gratis Design erhalten
· Workflow · 6 Min. Lesezeit

Fastlane snapshot vs. no-code App-Store-Screenshots

Fastlane snapshot vs. no-code App-Store-Screenshots
TL;DR. Fastlane snapshot ist die richtige Wahl, wenn du bei jedem CI-Build rohe Simulator-Screenshots neu generieren willst. Browser-basierte no-code Tools sind die richtige Wahl, wenn du Marketing-Kompositionen mit Untertitel, Farbverläufen und mehrteiligen Karussells brauchst. Sie lösen angrenzende Probleme. Die meisten Teams nutzen am Ende beide.

Fastlane ist das kanonische Open-Source-Automatisierungs-Framework für iOS. Sein snapshot-Modul erstellt App-Store-Screenshots, indem es UI-Tests im Simulator über die konfigurierten Locales hinweg ausführt und rohe PNGs erzeugt, die der tatsächlichen App-Oberfläche entsprechen. Das Einrichten erfordert das Schreiben eines Snapfile, das Konfigurieren von UI-Tests und das Ausführen im CI.

Browser-basierte no-code Tools (Mokbi, AppLaunchpad, Previewed usw.) überspringen den Code-Teil — du lädst Screenshots manuell hoch und gestaltest Marketing-Karussells darüber.

Der Vergleich liegt auf einer anderen Achse als „welches ist besser“. Es geht um „welches löst dein Problem“.

Was Fastlane snapshot macht

Fastlanes snapshot führt deine App im Simulator über beliebig viele Locales und Geräteklassen aus, die du konfigurierst. Für jede Kombination führt es UI-Test-Skripte aus, die die App in bestimmte Zustände steuern, und erfasst dann den Simulator-Bildschirm. Ergebnis: rohe PNG-Screenshots der tatsächlich laufenden App, einer pro Locale × Gerät × Test-Szenario.

Stärken:

  • CI-integriert. Screenshots werden bei jedem Release-Build neu generiert. Immer synchron mit der tatsächlichen App.
  • Screenshots in echter Locale. Jede Locale läuft im Simulator mit den tatsächlichen Locale-Einstellungen — Datumsangaben, Zahlen und Währungen werden nativ dargestellt.
  • Kostenlos und Open Source. Kein Abo.
  • Kein Auseinanderdriften von Code und Screenshots. Wenn du ein UI-Element änderst, nimmt der nächste CI-Lauf es automatisch mit.

Schwächen:

  • Ausgabe sind rohe Simulator-Screenshots. Keine Untertitel, keine Marketing-Overlays, keine Farbverlauf-Hintergründe, keine mehrteiligen Karussells. Nur die App-Oberfläche.
  • Der Einrichtungsaufwand ist real. Das Schreiben des Snapfile, das Konfigurieren von UI-Tests für die Screenshot-Aufnahme, das Debuggen unvermeidlicher Simulator-Zustandsprobleme — typischerweise ein bis zwei Tage Arbeit beim ersten Mal.
  • Wartungsaufwand. UI-Änderungen brechen UI-Tests. Jedes App-Update erfordert Anpassungen der Snapshot-Skripte.
  • Nur iOS. Android hat eigenes Tooling (fastlane screengrab).
  • Mac erforderlich. Der iOS-Simulator braucht Xcode.

Was no-code Browser-Tools machen

Screenshots auf beliebige Weise aufnehmen (manuell vom Telefon, Simulator-Screenshots oder sogar via Fastlane snapshot, wenn du es bereits eingerichtet hast). In einen Browser-Editor laden. Geräterahmen, Untertitel und Farbverlauf-Hintergründe hinzufügen. Untertitel je Locale übersetzen. In allen App-Store-Abmessungen exportieren.

Stärken:

  • Kein Code, keine Einrichtung. Editor öffnen und loslegen.
  • Marketing-Komposition. Untertitel, Farbverläufe, mehrteilige Karussells — die eigentliche Marketing-Oberfläche, nicht nur rohe Screenshots.
  • Plattformübergreifend. Ein Projekt, beide Stores (App Store + Play Store).
  • Kein Mac erforderlich. Browser läuft überall.
  • Lokalisierungs-Automatisierung. Batch-Übersetzung per Klick für alle 50 App-Store-Sprachen.

Schwächen:

  • Screenshots können von der App abweichen. Wenn du eine UI-Änderung auslieferst, sind deine Screenshots veraltet. Die Korrektur ist manuell.
  • Quell-Screenshots müssen manuell aufgenommen werden. Jemand muss sie aufnehmen (aus dem Simulator, vom Gerät oder per Kopplung via WebRTC).
  • Keine CI-Integration. Das Marketing-Karussell wird nicht bei jedem Build automatisch neu generiert.

Der ehrliche Vergleich

Fastlane snapshot löst das Problem: „Ich möchte, dass meine Screenshots automatisch bei jedem Build und in jeder Locale mit der tatsächlichen App übereinstimmen, ohne manuelle Aufnahme“. Die Ausgabe ist zweckorientiert — rohe Screenshots, keine Marketing-Assets.

Browser-Tools lösen das Problem: „Ich möchte ein poliertes Marketing-Karussell, an dem ich schnell iterieren kann, mit Untertitel, Farbverläufen und mehrteiliger Komposition, das für beide Stores bereitgestellt wird“. Die Quell-Screenshots müssen irgendwoher kommen; wie sie aufgenommen werden, ist nicht das Problem des Tools.

Diese konkurrieren nicht. Sie sind aufeinanderfolgende Schritte in derselben Pipeline.

Der realistische kombinierte Workflow

  1. Fastlane snapshot (oder manuelle Aufnahme) für Quell-Screenshots. Im CI ausführen für die App-Zustände, die du im Karussell zeigen möchtest.
  2. Browser-Tool für die Marketing-Komposition. Quell-Screenshots in den Editor laden, das Karussell mit Untertitel und Farbverläufen aufbauen.
  3. Übersetzen und Batch-Export aus dem Browser-Tool. An App Store Connect und die Play Console ausliefern.
  4. Beim nächsten App-Update Fastlane neu ausführen, um die Quellen zu regenerieren, das JSON-Projekt im Browser-Tool wieder öffnen, die Screenshots austauschen und erneut exportieren.

Wann du Fastlane weglassen kannst

Für die meisten Indie-Apps, die selten veröffentlichen (1–3 Releases pro Jahr), rechnet sich der Fastlane-Einrichtungsaufwand nicht. Manuelle Screenshot-Aufnahme einmal pro Release (vom Telefon auf den Desktop via WebRTC funktioniert gut dafür) plus browser-basierte Marketing-Komposition erledigt den Job in weniger Gesamtzeit.

Fastlane glänzt, wenn du wöchentlich oder täglich auslieferst und das Screenshot-Abdriften zu einem echten Problem wird. Für Agenturen, ausgereifte Produkte mit häufigen Releases und Teams mit bestehender iOS-CI-Infrastruktur gewinnt Fastlane bei der Quellaufnahme. Kombiniere es mit dem Browser-Tool für die Marketing-Komposition.

Was du als Nächstes liest

Editor öffnen →