Symptom: Ihre App öffnet sich im UI-Test, aber die Screenshots fehlen, zeigen die falsche Sprache oder passen nicht zu den vorgesehenen Store-Materialien.
Schnellste Lösung: Verwenden Sie fastlane snapshot zusammen mit Xcode UI-Tests, fixieren Sie zuerst Sprache, Simulatorziele und Testdaten und prüfen Sie danach jede erzeugte Aufnahme. Screenshot-Erzeugung, Größen- und Inhaltskontrolle sowie Upload sind getrennte Arbeitsschritte.
Dieser Leitfaden ist für Sie geeignet, wenn Sie eine lokalisierte iOS-App allein pflegen, die Sprachfassungen eines internationalen Produkts reproduzierbar aufnehmen oder Screenshot-Tests auf einem Remote Mac betreiben. Wenn Sie lediglich ein einzelnes Bild manuell bearbeiten möchten, brauchen Sie diesen Automatisierungsablauf nicht.
SECTION 01Für welche Aufgaben ist fastlane snapshot die passende Wahl?
fastlane snapshot automatisiert den Weg vom UI-Test zur Screenshot-Datei: Die App wird auf konfigurierten Simulatoren gestartet, ein Test führt sie durch die vorgesehenen Bildschirme, und die Aufnahmen werden in einem Ausgabeordner abgelegt. Die fastlane-Dokumentation zum Screenshot-Workflow beschreibt diesen Ablauf mit mehreren Sprachen und Simulatorzielen.
Das ist besonders nützlich, wenn sich Bildschirmtexte, Navigation oder lokalisierte Inhalte regelmäßig ändern. Statt jede Sprachfassung manuell zu öffnen und abzufotografieren, können Sie denselben Testablauf wiederholt ausführen. Der Nutzen entsteht aber nur, wenn Ihr Test zuverlässig denselben sichtbaren Zustand erreicht.
Drei Abgrenzungen verhindern typische Fehlannahmen:
- Ein erfolgreicher UI-Test bedeutet nicht automatisch, dass jedes gewünschte Bild gespeichert wurde.
- Eine vorhandene Datei ist nicht automatisch ein korrektes Store-Motiv: Sie kann die falsche Sprache, einen Ladezustand oder unpassende Inhalte zeigen.
- Ein fertiger Screenshot-Ordner bedeutet weder, dass die aktuellen Spezifikationen erfüllt sind, noch, dass die Bilder bereits in App Store Connect hochgeladen wurden.
Die technische Aufnahme ist also ein Baustein Ihrer Materialkette und kein Ersatz für die redaktionelle Prüfung oder den Einreichungsschritt.
Einzelentwickler: Erst einen stabilen Bildschirmpfad herstellen
Wenn Sie eine App allein betreuen, beginnen Sie nicht mit einer großen Geräte- und Sprachkombination. Stellen Sie zunächst sicher, dass ein UI-Test die App reproduzierbar öffnet, den vorgesehenen Bildschirm erreicht und dort nicht an einem Dialog, einer Anmeldung oder einer noch laufenden Animation hängen bleibt.
Für einen ersten Probelauf genügt ein klar definierter Pfad durch die App. Verwenden Sie kontrollierte Testdaten, damit beispielsweise ein leerer Zustand nicht gelegentlich anstelle der erwarteten Produktansicht erscheint. Wenn die Teststrecke instabil ist, vervielfacht jede zusätzliche Lokalisierung oder jedes weitere Gerät nur die Zahl der Fehlerstellen. Stabilisieren Sie zuerst den Ablauf, erweitern Sie anschließend die Konfiguration.
Teams für internationale Apps: Sprachfassung und Gebietsschema getrennt prüfen
Bei einer lokalisierten App müssen Sie nicht nur übersetzte Texte kontrollieren. Auch Datumsangaben, Zahlenformate, abgekürzte Beschriftungen und unterschiedlich lange Wörter können das Layout verändern. Ein Dateiname mit einer Sprachkennung beweist nicht, dass die App während der Aufnahme tatsächlich die erwartete Sprache verwendet.
Die Dokumentation zum Testen von Lokalisierungen beim App-Start beschreibt, wie sich lokalisierte Läufe prüfen lassen. Nutzen Sie diese Möglichkeit, um zu bestätigen, dass Ihre Tests mit den gewünschten Spracheinstellungen starten. Die Anleitung von Apple zu Screenshots für Lokalisierungsteams hilft außerdem dabei, die Aufnahmen als überprüfbares Material für die Lokalisierung einzuordnen.
Achten Sie im Test darauf, was tatsächlich auf dem Bildschirm steht. Ein plausibler lokalisierter Titel reicht nicht, wenn ein Datum noch im falschen Format erscheint oder ein dynamisch geladener Bereich leer bleibt. Prüfen Sie außerdem, ob die App beim Wechsel zwischen Gebietsschemata ihren Zustand sauber zurücksetzt. Andernfalls kann ein vorheriger Lauf etwa eine Auswahl, einen Hinweis oder den Anmeldestatus in die nächste Aufnahme übernehmen.
Kleine Teams: Die Geräteauswahl an sichtbaren Unterschieden ausrichten
Mehr Simulatorziele machen eine Screenshot-Sammlung nicht automatisch vollständiger. Wählen Sie Ziele danach aus, welche Plattformen Ihre App unterstützt, welche Layouts sich tatsächlich unterscheiden und welche Materialien Sie einreichen möchten. Für einen Bildschirm, der auf allen vorgesehenen Geräten gleich aufgebaut ist, kann ein repräsentatives Ziel für die frühe Kontrolle genügen. Sichtbare Abweichungen bei Navigation, Inhalt oder Darstellung sprechen dagegen für zusätzliche Prüfungen.
Die Apple-Dokumentation zum Ausführen einer App auf simulierten oder physischen Geräten erläutert den Einsatz der jeweiligen Ziele. Konfigurieren Sie nicht blind jede verfügbare Variante. Ein größeres Testfeld verlängert die Fehleranalyse und kann mehr Wartungsaufwand erzeugen, ohne dass Sie dadurch ein besseres Store-Set erhalten.
| Vorgehen | Geeignet, wenn … | Vorteile | Grenzen und Prüfbedarf |
|---|---|---|---|
| Ein Simulatorziel und eine Sprache | Sie den UI-Testpfad erstmals stabilisieren | Fehler lassen sich leichter einer Ursache zuordnen; kurze Rückkopplung beim Einrichten | Belegt keine korrekte Darstellung in anderen Sprachen oder Layouts |
| Mehrere Sprachen auf ausgewählten Simulatorzielen | Sie lokalisierte Fassungen regelmäßig kontrollieren | Wiederholbare Aufnahmen und vergleichbare Sprachstände | Gebietsschema, Testdaten und sichtbarer Bildinhalt müssen je Lauf geprüft werden |
| Breite Geräte- und Sprachmatrix | Ihre App zeigt nachweislich relevante Layoutunterschiede | Deckt mehr Kombinationen des tatsächlichen Produktumfangs ab | Mehr Laufvarianten, längere Fehlersuche und höherer Pflegebedarf; ersetzt keine Store-Abnahme |
Die Konfigurationselemente für snapshot, darunter Sprachen, Geräte und Ausgabeoptionen, sind in der Referenz zur fastlane-Aktion snapshot beschrieben. Prüfen Sie beim Einrichten die dort dokumentierten Optionen gegen Ihre installierte Toolchain, statt eine Konfiguration aus einem anderen Projekt unverändert zu übernehmen.
Remote-Mac-Betrieb: Sitzung und Ausgabe nachvollziehbar halten
Ein Remote Mac kann UI-Tests und Simulatoren ausführen, sofern die benötigten Projekt- und Entwicklungsumgebungen vorhanden sind. Daraus folgt nicht, dass jedes konfigurierte Simulatorziel bereits installiert ist oder dass ein unbeaufsichtigter Lauf stabil durchläuft. Auf einem entfernten System kommt eine weitere Fehlerquelle hinzu: Nach Ende der Sitzung müssen Sie noch auf Protokolle und erzeugte Dateien zugreifen können.
Wenn Sie einen solchen Ablauf betreiben, fixieren Sie Projektstand und Toolchain für den Lauf. Legen Sie den Ausgabeort fest und prüfen Sie, ob er außerhalb einer temporären Sitzung erhalten bleibt. Sichern Sie neben den Bildern auch den Testbericht und relevante Protokolle. Damit können Sie unterscheiden, ob ein Test gar nicht abgeschlossen, eine Aufnahme nicht erzeugt oder ein Bild mit falschem Inhalt gespeichert wurde.
Achtung: Behandeln Sie einen grünen Testlauf nicht als Screenshot-Abnahme. Der Teststatus sagt aus, ob die ausgeführten Testschritte bestanden wurden; er bestätigt nicht automatisch Sprache, Vollständigkeit, Lesbarkeit oder Einreichbarkeit aller Bilder.
Die Organisation von Testplänen kann helfen, unterschiedliche Testvarianten nachvollziehbar zu verwalten. Apple beschreibt diese Möglichkeiten in der Dokumentation zum Organisieren von Tests für besseres Feedback. Nutzen Sie die Struktur, um Varianten und erwartete Ergebnisse auseinanderzuhalten; sie ersetzt nicht die Kontrolle der erzeugten Dateien.
SECTION 02Wie richten Sie den Ablauf reproduzierbar ein?
Gehen Sie in dieser Reihenfolge vor. So erkennen Sie früh, ob ein Problem in der Lokalisierung, im Testpfad, beim Simulator oder erst in der Materialabnahme liegt.
- Projekt und UI-Test festlegen. Wählen Sie den App-Scheme und den UI-Test, der den gewünschten Bildschirm erreicht. Starten Sie den Test zunächst ohne Screenshot-Matrix und prüfen Sie, ob er wiederholbar denselben Zustand herstellt. Entfernen Sie manuelle Voraussetzungen, die im automatisierten Lauf fehlen würden.
- Sprache und Gebietsschema auswählen. Tragen Sie die beabsichtigten Lokalisierungen in die fastlane-Konfiguration ein und kontrollieren Sie, ob der Lauf mit der passenden Sprache startet. Prüfen Sie danach auch sprachabhängige Datums- und Zahlenformate. Verlassen Sie sich nicht auf die Bezeichnung der späteren Bilddatei.
- Simulatorziele begrenzen. Wählen Sie nur die Geräte, die für Ihre App und die vorgesehenen Materialien relevant sind. Vergewissern Sie sich, dass die Zielgeräte auf dem ausführenden Mac verfügbar sind. Für die Grundlagen zur Bedienung und Auswahl von Simulatoren können Sie Apples Hinweise zu simulierten und physischen Geräten heranziehen.
- Testdaten und Bildschirme stabilisieren. Bereiten Sie vorhersehbare Daten vor, schließen Sie variable Ladezustände aus und führen Sie den Test bis zu jedem gewünschten Motiv. Wenn ein Bildschirm von Netzwerkdaten abhängt, muss der Test auch mit einem langsamen oder fehlgeschlagenen Abruf sinnvoll umgehen. Sonst kann derselbe Screenshot bei späteren Läufen etwas anderes zeigen.
- Ausgabeordner festlegen und den Lauf ausführen. Nach der fastlane-Dokumentation werden Screenshots standardmäßig unter
fastlane/screenshotsabgelegt; die Ausgabe lässt sich konfigurieren. Halten Sie den gewählten Pfad im Team fest. So finden Sie die Bilder später wieder und können prüfen, ob sie beim Remote-Lauf dauerhaft gespeichert wurden. - Ergebnisdateien mit dem Testbericht abgleichen. Vergleichen Sie die erwarteten Sprach-, Geräte- und Motivkombinationen mit den vorhandenen Dateien. Kontrollieren Sie den Testbericht und die Protokolle für fehlgeschlagene Läufe. Eine fehlende Datei kann auf einen Testabbruch, einen nicht erreichten Bildschirm oder ein Speicherproblem hindeuten; die Ursache sollten Sie aus den Laufspuren ableiten.
- Bilder visuell und technisch abnehmen. Öffnen Sie die Aufnahmen und prüfen Sie Sprache, Inhalt, abgeschnittene Beschriftungen, Ladeanzeigen und unerwartete Dialoge. Kontrollieren Sie anschließend die Anforderungen für die vorgesehenen Geräte. Apples aktuelle Screenshot-Spezifikationen für App Store Connect sind dafür maßgeblich; prüfen Sie sie vor der Einreichung erneut, statt dauerhaft mit alten Vorgaben zu arbeiten.
- Upload separat durchführen und bestätigen. Laden Sie erst nach der Abnahme hoch und prüfen Sie danach den Status im vorgesehenen App-Store-Connect-Bereich. Apple führt den Upload von App-Vorschauen und Screenshots als eigenen Vorgang. Bei automatisierten Abläufen kann auch die Dokumentation zu App-Screenshots über die App-Store-Connect-API relevant sein. Ein lokal erfolgreiches Erzeugen bestätigt für sich genommen keinen erfolgreichen Upload.
Für den Lauf selbst können Sie fastlane snapshot in die vorhandene fastlane-Ausführung integrieren. Legen Sie die tatsächlichen Namen Ihres Schemes, die unterstützten Sprachen, Simulatorziele und den Ausgabeordner in der projektbezogenen Konfiguration fest. Übernehmen Sie keine Gerätenamen oder Testannahmen aus Beispielen, ohne sie gegen Ihr Projekt und die lokale Xcode-Umgebung zu prüfen.
SECTION 03Woran erkennen Sie, welche Fehlerart vorliegt?
Unterscheiden Sie Fehler nach dem ersten Beleg, den Sie finden:
- Test nicht abgeschlossen: Der UI-Testbericht zeigt einen Abbruch oder einen fehlgeschlagenen Schritt. Untersuchen Sie zuerst den Testpfad und die App-Zustände.
- Bild nicht vorhanden: Der Test ist möglicherweise durchgelaufen, aber die erwartete Aufnahme fehlt. Prüfen Sie Screenshot-Schritt, Ausgabeordner und Protokolle.
- Bild vorhanden, aber falsch: Kontrollieren Sie Sprache, Gebietsschema, Testdaten und den sichtbaren Bildschirm. Eine Datei kann technisch gültig und inhaltlich trotzdem ungeeignet sein.
- Bild korrekt, aber nicht einreichbar: Vergleichen Sie die Datei mit den aktuellen Spezifikationen für das jeweilige Ziel und prüfen Sie den Upload separat.
Hinweis: Bewahren Sie für einen fehlgeschlagenen Lauf mindestens Testbericht, relevante Protokolle und die erzeugten Aufnahmen auf. Ohne diese Belege ist es schwer, zwischen „Test nicht fertig“, „Screenshot fehlt“ und „Screenshot inhaltlich falsch“ zu unterscheiden.
Bei dynamischen Inhalten lohnt sich eine bewusste Teststrategie. Verwenden Sie für Screenshot-Tests kontrollierte Zustände, und vermeiden Sie, dass Werbeeinblendungen, zufällige Inhalte oder zeitabhängige Meldungen das Motiv verändern. Bei Animationen sollte der Test erst dann aufnehmen, wenn die vorgesehene Ansicht stabil sichtbar ist. Das ist keine kosmetische Feinheit: Eine Aufnahme aus einem Übergang kann Überschriften verdecken oder einen unvollständigen Bildschirm zeigen, obwohl der Test technisch keinen Fehler meldet.
SECTION 04Häufige Fragen zu fastlane snapshot und lokalisierten Aufnahmen
Wie stellen Sie sicher, dass tatsächlich die gewünschte Sprache aufgenommen wird?
Prüfen Sie die Spracheinstellung des Laufs und die Darstellung in der App selbst. Achten Sie außerdem auf Gebietsschema-abhängige Werte wie Datum oder Zahlen. Eine lokalisierte Dateibenennung ist nur eine Zuordnungshilfe, kein Nachweis für den Bildinhalt. Bei Abweichungen sollten Sie den Testbericht und den App-Zustand untersuchen, bevor Sie die gesamte Matrix erneut starten.
Wo finden Sie die erzeugten Screenshots, und was gilt als vollständig?
Der Standardpfad ist fastlane/screenshots; wenn Sie einen anderen Ausgabeordner festgelegt haben, gilt dieser Projektpfad. Vollständig ist die Sammlung erst, wenn die erwarteten Motive für die gewählten Kombinationen vorhanden und visuell kontrolliert sind. Nutzen Sie Testberichte und Protokolle, um zwischen einem abgebrochenen Test und einer fehlenden oder fehlerhaften Aufnahme zu unterscheiden.
Erzeugt die Automatisierung Bilder in mehreren Gerätegrößen?
Sie kann Aufnahmen für mehrere konfigurierte Simulatorziele erstellen. Entscheidend ist, dass die Auswahl Ihre Plattformen und sichtbaren Layoutunterschiede abbildet. Prüfen Sie zusätzlich die aktuellen Einreichungsanforderungen für die jeweiligen Store-Materialien. Eine größere Simulatorauswahl allein beweist weder, dass alle benötigten Dateien vorhanden sind, noch, dass jede davon akzeptiert wird.
Was muss vor einem unbeaufsichtigten Lauf auf einem Remote Mac bereitstehen?
Halten Sie Projektstand, Xcode-Toolchain, Test-Scheme, UI-Test, Lokalisierungen, Simulatorziele und Ausgabeort fest. Stellen Sie außerdem sicher, dass Testdaten vorhersehbar sind und dass Protokolle sowie Bilder nach der Sitzung erhalten bleiben. Führen Sie vor dem unbeaufsichtigten Betrieb einen kontrollierten Probelauf aus; ein gestarteter Prozess belegt nicht, dass alle Simulatorziele vorhanden und sämtliche Screenshots korrekt sind.
SECTION 05Wann ist ein Remote Mac die passende Ergänzung?
Wenn Sie Ihre Screenshots bisher auf einem einzelnen lokalen Mac erzeugen, behalten Sie dessen Vorteile im Blick: Sie kennen die Umgebung, können direkt eingreifen und benötigen keinen zusätzlichen Remote-Zugriff. Nachteile entstehen, wenn die Maschine für unbeaufsichtigte Läufe verfügbar bleiben muss, Projektdateien und Simulatoren lokalen Speicher beanspruchen oder ein eigens für CI angeschafftes Gerät außerhalb der Testläufe ungenutzt bleibt.
Für gelegentliche Aufnahmen ist ein vorhandener Mac meist die einfachste Wahl. Wenn Sie dagegen wiederkehrende Tests und Screenshot-Läufe von Ihrem Arbeitsrechner entkoppeln möchten, kann ein gemieteter Mac eine flexiblere Testumgebung sein. Bei MACNOX können Sie die Mac-Umgebung für Remote-Arbeit und die verfügbaren Mietoptionen prüfen, bevor Sie entscheiden, ob sie zu Ihrem Umfang passt. Sie brauchen trotzdem einen festen Projektstand, installierte passende Simulatorziele und eine Ablage für Protokolle und Bilder; die Miete macht einen instabilen UI-Test nicht automatisch zuverlässig.
Der verlässliche Ablauf bleibt derselbe: Sprache, Simulator und Testdaten festlegen, Aufnahmen erzeugen, Ergebnisse kontrollieren und Store-Vorgaben sowie Upload separat abnehmen. Wenn Sie diese Schritte bereits automatisieren, aber die Tests nicht an Ihren lokalen Mac binden möchten, prüfen Sie als Nächstes, ob ein Remote Mac Ihre benötigten Simulatorziele und die dauerhafte Sicherung der Artefakte abdeckt.
SECTION 06FAQ
Wie steuert fastlane snapshot die Sprache eines Screenshots?
Legen Sie die gewünschten Gebietsschemas in der snapshot-Konfiguration fest und prüfen Sie anschließend im UI-Test, ob die App tatsächlich in der erwarteten Sprache startet. Sprache und Region können sich auf Datums-, Zahlen- und Textdarstellung auswirken. Kontrollieren Sie deshalb den Bildinhalt und nicht nur den Dateinamen oder den erfolgreichen Lauf des Tests.
In welchem Ordner liegen die erzeugten Bilder, und wie erkennen Sie fehlende Aufnahmen?
fastlane snapshot legt Bilder standardmäßig im Verzeichnis fastlane/screenshots ab; ein abweichender Ausgabeordner lässt sich konfigurieren. Vergleichen Sie nach jedem Lauf die erwarteten Kombinationen aus Sprache, Gerät und Screenshot-Schritt mit den vorhandenen Dateien. Prüfen Sie außerdem den Testbericht und die Protokolle, damit ein fehlendes Bild nicht mit einem erfolgreichen, aber unvollständigen Lauf verwechselt wird.
Kann ein Lauf Screenshots für verschiedene Simulatorgeräte erstellen?
Ja. Sie können mehrere passende Simulatorziele konfigurieren und Screenshots in einem automatisierten Lauf erzeugen lassen. Das ersetzt jedoch keine Prüfung der App-Store-Anforderungen: Eine andere Simulatorgröße bedeutet nicht automatisch, dass jede benötigte Bildvariante vorhanden oder für die Einreichung geeignet ist. Wählen Sie Geräte nach Plattform, sichtbaren Layoutunterschieden und tatsächlichem Materialbedarf.
Welche Voraussetzungen braucht fastlane snapshot auf einem Remote Mac?
Der Remote Mac benötigt ein verfügbares Projekt mit passenden UI-Tests, die vorgesehene Xcode-Toolchain und die tatsächlich ausgewählten Simulatorziele. Halten Sie Projektversion, Testdaten und Ausgabeordner fest und sichern Sie Testberichte sowie Screenshots außerhalb einer flüchtigen Sitzung. Ein erfolgreicher Start belegt weder, dass jedes Ziel installiert ist, noch dass alle Aufnahmen vollständig oder inhaltlich korrekt sind.