Wie erstellt fastlane snapshot automatisch iOS-Store-Screenshots? 2026

Wenn fastlane snapshot iOS-Store-Screenshots automatisch erstellen soll, lassen Sie zuerst einen repräsentativen UI-Test in Xcode stabil laufen und erweitern Sie danach die Erfassung auf Sprachen und Simulatorziele. Das funktioniert nur in einer Umgebung mit macOS, Xcode und den passenden iOS-Simulatoren.

Dieser Leitfaden richtet sich an unabhängige Entwickler, die Store-Material für mehrere Sprachen vorbereiten und wiederholte manuelle Aufnahmen reduzieren möchten.
Er hilft kleinen Teams, Screenshots für ihre unterstützten Simulatorziele reproduzierbar zu organisieren.
Auch ohne lokalen Mac finden Sie hier die Prüfungen, mit denen Sie feststellen, ob ein Remote-Mac Ihre UI-Tests ausführen kann.

Der erste Meilenstein: eine einzelne Screenshot-Strecke

fastlane snapshot nimmt Ihnen nicht die Gestaltung Ihrer App-Oberfläche ab. Es automatisiert die Aufnahme von Screenshots, indem UI-Tests die App in die gewünschten Zustände bringen. Der entscheidende Startpunkt ist deshalb nicht eine umfangreiche Geräte- oder Sprachliste, sondern ein Test, der auf einem Simulator zuverlässig die richtigen Ansichten erreicht.

Die offizielle fastlane-Anleitung zur Screenshot-Erstellung beschreibt die Einrichtung und Ausführung. Lesen Sie dort die aktuellen Schritte für Ihre Projektumgebung, statt Konfigurationsbeispiele ungeprüft aus älteren Projekten zu übernehmen. Die Dokumentation zum capture_ios_screenshots-Aufruf ergänzt die verfügbaren Konfigurationsmöglichkeiten.

Vor dem ersten fastlane-Lauf sollten drei Projektbedingungen stimmen:

• Ihr Projekt enthält ein UI-Test-Target, das die App starten und die vorgesehene Ansicht erreichen kann.
• Das verwendete Scheme ist für die Ausführung außerhalb der lokalen Xcode-Oberfläche verfügbar.
• Der Test hat klar definierte Aufnahmezeitpunkte und erreicht sie ohne manuelle Eingaben.

Prüfen Sie den UI-Test zunächst in Xcode. Bestätigen Sie, dass er die erwartete Ansicht erreicht, nicht vor der Aufnahme abbricht und keine Anmeldung oder Interaktion voraussetzt, die nur auf Ihrem Entwicklungsgerät vorhanden ist. Danach führen Sie fastlane für genau diesen Ablauf aus. Erst wenn die Ergebnisdateien erzeugt wurden und die Bilder den richtigen Zustand zeigen, ist der erste Meilenstein erreicht.

Die folgende Gegenüberstellung hilft, einen fehlgeschlagenen Lauf richtig einzuordnen:

Behandeln Sie dabei „Test bestanden“, „Screenshot erzeugt“ und „Store-Material korrekt hochgeladen“ als getrennte Ergebnisse. Ein grüner UI-Test beweist nicht, dass die erzeugte Datei die richtige Sprache zeigt. Eine vorhandene Datei beweist ebenso wenig, dass sie dem richtigen Store-Eintrag zugeordnet wurde.

Mehrere Sprachen: App-Oberfläche und Store-Sprache getrennt prüfen

Bei mehrsprachigen Projekten muss die Aufnahme die tatsächlich lokalisierte App-Oberfläche zeigen. Die Sprache, die Ihre App zur Laufzeit anzeigt, und die Sprache der Store-Metadaten sind jedoch unterschiedliche Einstellungen. fastlane kann die Screenshot-Erfassung nach Sprachen organisieren; daraus folgt nicht, dass die Store-Sprachversionen oder ihre Metadaten automatisch eingerichtet sind. Prüfen Sie die aktuelle Sprachkonfiguration in der fastlane-Screenshot-Dokumentation.

Legen Sie für jede gewünschte Sprache fest, wie der UI-Test die passende App-Sprache erhält. Das kann von der Projektkonfiguration und der Testumgebung abhängen. Verlassen Sie sich nicht allein auf den Namen eines Ausgabeordners: Öffnen Sie die Bilder und prüfen Sie, ob Navigation, Schaltflächen und weitere sichtbare Texte tatsächlich in der erwarteten Sprache erscheinen.

Auch Testdaten müssen zur Sprache passen. Ein fest codierter Name, ein Datum oder ein Text aus einer Serverantwort kann in einer ansonsten lokalisierten Ansicht die falsche Sprache zeigen. Entscheiden Sie vor der Aufnahme, ob die Darstellung echte Produktinhalte oder kontrollierte Testdaten abbilden soll. Dokumentieren Sie die Wahl im Projekt, damit spätere Läufe vergleichbare Ergebnisse liefern.

Die Trennung ist besonders wichtig, wenn Sie Screenshots automatisiert hochladen. Die Dokumentation zu deliver beschreibt die Upload-Funktion für App-Store-Inhalte. Verwenden Sie sie erst, nachdem die lokalen Dateien visuell geprüft und den vorgesehenen App- und Sprachbereichen zugeordnet wurden. Das bloße Vorhandensein einer Datei ist keine Bestätigung ihrer richtigen Einreichung.

Mehrere Simulatoren: Abdeckung nach unterstützten Zielen planen

fastlane snapshot kann Screenshot-Läufe für konfigurierte Simulatorziele organisieren. Wählen Sie die Ziele anhand des tatsächlichen Umfangs Ihres Projekts, nicht nach einer pauschalen Annahme, dass ein einziger Lauf alle Geräte abdeckt. Ein erfolgreicher Durchlauf auf einem Simulator bestätigt zunächst nur diesen getesteten Fall.

Erstellen Sie in der fastlane-Konfiguration eine nachvollziehbare Zuordnung zwischen Simulatorziel, Lauf und Ausgabe. Halten Sie die Ordnerstruktur so übersichtlich, dass Sie bei der Kontrolle erkennen, welches Bild aus welchem Lauf stammt. Nutzen Sie die von fastlane dokumentierten Konfigurationsoptionen und verifizieren Sie ihr Verhalten mit Ihrer installierten Werkzeugversion.

Apple dokumentiert, wie simulierte und physische Geräte in Xcode verwaltet werden, im Leitfaden zum Device Hub. Für die Einordnung der Store-Materialien gelten die jeweils aktuellen App-Store-Screenshot-Spezifikationen. Prüfen Sie diese Anforderungen direkt für die vorgesehenen Zielgeräte und Store-Einträge. Übernehmen Sie keine alte Gerätezuordnung aus einer anderen App als allgemeingültige Vorgabe.

Eine zweckmäßige Abdeckungsmatrix enthält pro Ziel:

• die Projekt- oder Gerätezuordnung,
• den ausgeführten UI-Test,
• den Status des Laufs,
• den Ablageort der Dateien,
• das Ergebnis der visuellen Kontrolle.

Fehlt ein Simulatorziel in der Konfiguration, darf ein erfolgreicher Lauf der übrigen Ziele nicht als vollständige Geräteabdeckung dokumentiert werden. Wenn das Projekt eine Geräteklasse nicht unterstützt oder nicht für sie getestet werden soll, halten Sie diese Einschränkung ebenfalls fest. So vermeiden Sie, dass ein Ordner voller Bilder fälschlich als Nachweis für eine vollständige Prüfung gilt.

Apple beschreibt außerdem die Aufnahme von Bildern und Videos von Geräten in der Dokumentation zur Screenshot-Erfassung. Das ist eine nützliche Referenz für manuelle Kontrollen und Alternativaufnahmen. Es ersetzt jedoch nicht die Prüfung, ob Ihre fastlane-Konfiguration alle vorgesehenen Simulatorziele tatsächlich ausführt.

Schwankende Bilder: zuerst den UI-Test und App-Zustand stabilisieren

Wenn Screenshots zwischen Läufen abweichen, liegt die Ursache häufig im erreichten App-Zustand und nicht im Bilddateiformat. Prüfen Sie zuerst, ob der UI-Test immer dieselbe Ansicht erreicht und ob die dargestellten Inhalte während der Aufnahme bereits vollständig geladen sind. Behandeln Sie eine Wartebedingung nicht als Garantie gegen jede Schwankung: Sie muss zum konkreten Ablauf passen und in Ihrer Umgebung verifiziert werden.

Gehen Sie Fehlerquellen in einer festen Reihenfolge durch:

1. Anmeldung: Legen Sie fest, ob der Test einen reproduzierbaren Testzugang verwendet oder einen bereits vorhandenen Sitzungszustand voraussetzt. Vermeiden Sie Abhängigkeiten von einer Sitzung, die auf einem anderen Rechner erstellt wurde.
2. Netzwerkantworten: Ermitteln Sie, ob wechselnde oder verzögerte Inhalte das Erscheinungsbild beeinflussen. Soweit es Ihr Projekt zulässt, verwenden Sie für Screenshot-Tests kontrollierte Antworten oder Testdaten.
3. Ladezustände: Stellen Sie sicher, dass die Aufnahme erst erfolgt, wenn die für das Bild relevanten Elemente sichtbar sind. Eine feste Pause allein beweist nicht, dass die App den benötigten Zustand erreicht hat.
4. Testdaten: Prüfen Sie, ob Inhalte zwischen Läufen verändert, sortiert oder entfernt werden. Ein Screenshot-Test sollte nicht davon abhängen, welche Daten ein vorheriger Lauf hinterlassen hat.
5. Wiederholungen: Nutzen Sie Wiederholungs- oder Wartefunktionen nur entsprechend der aktuellen fastlane-Dokumentation und dem Verhalten Ihres Tests. Wiederholungen können einen transienten Fehler sichtbar machen, aber keine fehlerhafte Testlogik korrigieren.

Die fastlane-Dokumentation beschreibt Funktionen zur Steuerung und Ausführung von Screenshot-Tests. Welche Option in Ihrem Fall greift, hängt von der Konfiguration und dem konkreten Fehler ab; prüfen Sie die Dokumentation der Screenshot-Aktion. Versprechen Sie sich nicht, dass eine einzelne Einstellung jede Netzwerkverzögerung oder jeden instabilen App-Zustand beseitigt. Entscheidend ist, dass der Test den Zustand reproduzierbar herstellt und Sie das Ergebnis wiederholt kontrollieren.

Remote-Mac-Ausführung: erst die Testumgebung abnehmen

Für fastlane snapshot benötigen Sie eine Umgebung, in der Xcode und iOS-Simulatoren laufen können. Apple erläutert die Verwaltung der simulierten Geräte im Device Hub. Ein Remote-Mac ist daher erst dann eine geeignete Screenshot-Umgebung, wenn Ihr Projekt-Scheme, die benötigte Simulatorlaufzeit und der UI-Test dort tatsächlich verfügbar sind.

Nutzen Sie diese Abnahme, bevor Sie eine automatisierte Screenshot-Aufgabe auf einen Remote-Rechner verlagern:

• [ ] Xcode lässt sich in der vorgesehenen Umgebung starten.
• [ ] Das benötigte Simulatorziel ist verfügbar und kann gestartet werden.
• [ ] Das verwendete Scheme und das UI-Test-Target sind auf dem Remote-Mac vorhanden.
• [ ] Der UI-Test erreicht die gewünschte App-Ansicht, ohne eine lokale manuelle Eingabe vorauszusetzen.
• [ ] fastlane beendet den Lauf mit einem überprüfbaren Ergebnis.
• [ ] Die Screenshot-Dateien werden tatsächlich erzeugt und im erwarteten Ablageort gespeichert.
• [ ] Die ausführende Sitzung kann auf die Ausgabedateien zugreifen und sie zur Sichtprüfung bereitstellen.

Führen Sie die Abnahme zunächst interaktiv aus. Erst danach sollten Sie dieselbe Strecke über die geplante Automatisierung starten. Das ist wichtig, weil eine Sitzung, die lokal auf Ihrem Mac funktioniert, andere Zugriffs- oder Anmeldebedingungen haben kann als ein automatisierter Remote-Lauf. Prüfen Sie außerdem, wie Projektdateien und Testzugänge übertragen und geschützt werden. Angaben zum Umgang mit Kontodaten sollten Sie mit den für Ihre Umgebung geltenden Datenschutzanforderungen abgleichen; die Datenschutzhinweise von MacUDP sind dabei eine Informationsquelle zum Dienst, kein Ersatz für Ihre eigene Projektprüfung.

Wenn Sie eine Remote-Umgebung evaluieren, können die verfügbaren MacUDP-Standorte ein Ausgangspunkt für die Planung sein. Verlassen Sie sich für eine Screenshot-Aufgabe aber nicht allein auf eine Produktbeschreibung: Maßgeblich ist, ob der benötigte Xcode- und Simulatorlauf in Ihrer konkreten Sitzung funktioniert und die Dateien anschließend erreichbar sind.

Vor dem Store-Upload: Dateien, Zuordnung und Ergebnis abnehmen

Die Erzeugung ist nur ein Teil des Ablaufs. Vor dem Upload prüfen Sie die Bilder auf veraltete Inhalte, falsche Sprache, unerwartete Testdaten und nicht passende Geräteansichten. Gleichen Sie die Dateien mit den aktuellen App-Store-Screenshot-Spezifikationen ab. Apple beschreibt außerdem den Prozess zum Hochladen von App-Vorschauen und Screenshots.

Unterscheiden Sie dabei drei Prüfergebnisse:

• Erzeugt: Die erwartete Bilddatei liegt am vorgesehenen Ablageort.
• Abgenommen: Sie haben Bildinhalt, Sprache, Ziel und Aktualität geprüft.
• Hochgeladen: Die Datei wurde dem vorgesehenen Eintrag zugeordnet und das Ergebnis des Uploads wurde kontrolliert.

Wird fastlane deliver eingesetzt, beachten Sie die aktuelle offizielle Dokumentation zu deliver. Kontrollieren Sie vor dem Ausführen, auf welche App und welche Inhalte der Upload zielt und welche vorhandenen Metadaten betroffen sein können. Lassen Sie einen automatisierten Upload nicht allein durch einen erfolgreichen Screenshot-Test auslösen, bevor Sie die konkrete Zuordnung und die endgültigen Dateien geprüft haben.

Eine erfolgreiche Erstellung sagt weder voraus, ob Apple die App freigibt, noch bestätigt sie, dass die Screenshots alle Prüfanforderungen erfüllen. Apple veröffentlicht eigene Richtlinien zu Screenshots im App Review. Nutzen Sie diese zusammen mit den aktuellen Materialvorgaben und prüfen Sie, ob die Bilder die App tatsächlich und korrekt darstellen.

Häufige Fragen

Wie entstehen Screenshots aus einem iOS-UI-Test mit fastlane snapshot?

Der UI-Test navigiert die App in einen festgelegten Zustand und löst an den vorgesehenen Stellen die Screenshot-Aufnahme aus. fastlane führt die konfigurierten Tests auf dem ausgewählten Simulator aus und organisiert die erzeugten Dateien. Prüfen Sie zuerst einen repräsentativen Ablauf in Xcode; die Aufnahme ist erst belastbar, wenn Testlauf, Dateiausgabe und dargestellter App-Zustand zusammenpassen.

Wie lassen sich Store-Screenshots für mehrere App-Sprachen erstellen?

Legen Sie fest, welche Sprachen Ihre App tatsächlich unterstützt, und konfigurieren Sie die Screenshot-Läufe passend dazu. Die Sprache der App-Oberfläche und die Sprache der Store-Metadaten sind getrennte Dinge: Eine erzeugte Aufnahme richtet die Metadaten nicht automatisch ein. Kontrollieren Sie daher je Ausgabeordner die sichtbare Sprache und ordnen Sie die geprüften Dateien anschließend der richtigen Store-Sprache zu.

Kann fastlane snapshot auf mehreren iOS-Simulatoren laufen?

Ja. Sie können die Simulatorziele für die Erfassung konfigurieren und die Läufe nach den tatsächlich unterstützten Geräteklassen Ihres Projekts ausrichten. Eine erfolgreiche Aufnahme auf einem Ziel belegt jedoch nicht, dass andere Bildschirmgrößen oder Konfigurationen geprüft wurden. Kontrollieren Sie deshalb pro Ziel den Teststatus, den Ausgabeort und die resultierenden Bilder, bevor Sie die Abdeckung als vollständig ansehen.

Wie kann ich fastlane snapshot ohne eigenen Mac ausführen?

Sie benötigen eine Umgebung, in der macOS, Xcode, das passende Simulatorlaufzeitsystem und Ihr Projekt-Scheme verfügbar sind. Ein Remote-Mac kann diese Aufgabe übernehmen, sofern der UI-Test dort tatsächlich startet und die Sitzung Zugriff auf die erzeugten Dateien hat. Testen Sie den Ablauf zuerst manuell in Xcode und prüfen Sie danach die automatisierte Ausführung samt Ablage, statt allein aus einem erfolgreichen Build auf funktionierende Screenshots zu schließen.

Wenn Sie nur gelegentlich Screenshots erzeugen, können manuelle Läufe auf einem vorhandenen Mac oder eine passende CI-Umgebung genügen. Der lokale Rechner kann dabei durch Speicherplatz und Verfügbarkeit begrenzt sein; eine nicht für macOS und Xcode eingerichtete Umgebung kann den UI-Test nicht einfach übernehmen. Ein dauerhaft hoch ausgelasteter Screenshot- oder Build-Betrieb kann dagegen den Kauf eines eigenen Mac sinnvoller machen als eine zeitweise Nutzung. Wenn Sie einen eigenständigen Mac benötigen, ohne dafür sofort Hardware anzuschaffen, prüfen Sie die MacUDP-Mietpläne und vergleichen Sie Laufhäufigkeit, Zugriff und benötigte Xcode-Umgebung mit Ihrem Projekt.

Häufig gestellte Fragen