Das Problem: 20 Apps, 20 Marken, Hunderte von Screenshots

Vor einigen Jahren arbeitete ich als Entwickler in einem Startup, wo wir eine Whitelabel Mobile App entwickelten. Eine Codebasis, aber 20 verschiedene Kunden — jeder mit eigenem Branding, eigenen Farben, Logos und App Store Einträgen. Jeder einzelne brauchte sein eigenes Set an polierten App Store und Google Play Screenshots.

Wer schon einmal eine App veröffentlicht hat, kennt das Spiel: Apple will Screenshots für jede Gerätegröße (6,7", 6,5", 5,5", iPad Pro, iPad...), Google Play will sein eigenes Set, und wenn man mehrere Sprachen unterstützt, multipliziert sich alles nochmal. Jetzt multipliziere das mit 20 Kunden.

Wir sprechen von Tausenden von Screenshots, die generiert, in Geräte-Mockups eingerahmt, mit den richtigen Farben gebrandet und hochgeladen werden mussten — bei jedem einzelnen Release-Zyklus.

Was wir hatten: Automatisierte Screenshots in der Pipeline

Die rohen Screenshots selbst waren nicht das Problem. Das hatten wir im Griff. Unsere UI-Tests, die in unserer GitLab CI Pipeline liefen, starteten jede App-Variante, navigierten durch die wichtigsten Screens und machten automatisch Screenshots. Fastlanes snapshot (iOS) und screengrab (Android) erledigten dort die schwere Arbeit.

Also landeten Hunderte von rohen PNG-Dateien nach jedem Build in unseren Pipeline-Artefakten. Großartig. Aber rohe Screenshots kommen nicht in den App Store. Sie müssen verarbeitet werden — in Geräterahmen platziert, mit einem Hintergrund versehen, der zur Marke des Kunden passt, mit Marketing-Text überlagert und in den exakten Pixelmaßen exportiert, die jeder Store verlangt.

Die Schmerzpunkte

1. Der Designer-Engpass

Unser Designer war talentiert, aber ihn zu bitten, Figma-Dateien für 20 Marken bei jedem Release manuell zu aktualisieren, war absurd. Er verbrachte Tage damit, Screenshots auszutauschen und Farben anzupassen. Und wenn ein Kunde mitten im Zyklus sein Branding änderte? Von vorne anfangen.

2. Keine Zeit für internes Tooling

Wir waren ein Startup. Jeder Sprint war vollgepackt mit Features, Bugfixes und Kundenanfragen. Einen internen Screenshot-Verarbeitungsservice zu bauen — mit Template-System, Geräterahmen-Rendering, Text-Overlay und store-spezifischem Export — war ein monatelanges Projekt, das wir einfach nicht rechtfertigen konnten. Wir mussten Produkt liefern, kein Tooling.

3. Manuelle Arbeit, die nicht skalierte

Eine Zeitlang versuchten wir einen halbmanuellen Ansatz: Der Designer erstellte Templates, ein Script verarbeitete sie im Batch, und jemand überprüfte und lud sie manuell hoch. Aber das ging ständig schief. Eine Schriftart war falsch, ein Rahmen passte nicht, der Text lief auf Deutsch über, sah aber auf Englisch gut aus. Jeder Sonderfall wurde zum Feuerwehreinsatz.

4. Pipeline-Integration war das fehlende Puzzlestück

Wir wollten einen vollautomatisierten Ablauf: Code wird gepusht, Pipeline führt Tests aus, Screenshots werden aufgenommen, Screenshots werden mit dem richtigen Branding verarbeitet, und Fastlane lädt sie in die Stores hoch. Das fehlende Stück war immer der Verarbeitungsschritt. Es gab keinen Service, den wir einfach aus unserer CI Pipeline per API aufrufen konnten.

Wie wir es gelöst haben

Diese Frustration ist genau der Grund, warum Screenshots Live existiert. Die Idee war einfach: ein Verarbeitungsservice, der rohe Screenshots nimmt, designererstellte Templates mit Geräterahmen und Branding anwendet und store-fertige Bilder zurückliefert — alles über einen einfachen API-Aufruf, der in jede CI/CD Pipeline passt.

Die GitLab + Fastlane Integration

So sah unsere Pipeline nach der Integration von Screenshots Live aus:

Build & Test Stage: GitLab CI baut die App für jede Whitelabel-Variante. UI-Tests laufen und nehmen rohe Screenshots mit Fastlane snapshot / screengrab auf.
Screenshot Processing Stage: Ein einfaches Script iteriert über die aufgenommenen Screenshots, ruft die Screenshots Live mit der richtigen Template-ID und den Branding-Parametern für jeden Kunden auf und lädt die verarbeiteten Bilder herunter.
Upload Stage: Fastlane deliver (iOS) und supply (Android) laden die verarbeiteten Screenshots in die jeweiligen Stores hoch.

Der gesamte Ablauf — vom Code-Push bis zu store-fertigen Screenshots — wurde vollständig automatisiert. Keine Designer-Beteiligung bei Routine-Releases. Keine manuelle QA von Screenshot-Layouts. Keine Feuerwehreinsätze, wenn ein Kunde freitags um 17 Uhr einen Hotfix-Release anforderte.

Was sich geändert hat

Zeitersparnis

Was früher 2-3 Designer-Tage pro Release-Zyklus dauerte, braucht jetzt null menschliche Zeit. Die Pipeline erledigt alles. Bei 20 Apps mit zweiwöchentlichen Releases sind das etwa 40-60 eingesparte Designer-Tage pro Jahr — Zeit, die unser Designer für echtes Produktdesign statt repetitiver Screenshot-Montage nutzen konnte.

Konsistenz

Jeder Screenshot, für jeden Kunden, für jede Gerätegröße, folgt dem exakt gleichen Template. Keine "die iPhone 15 Pro Max Version hat den Text leicht verschoben"-Probleme mehr. Die Templates sind pixelgenau, und sie werden jedes einzelne Mal konsistent angewendet.

Designer-Unabhängigkeit

Unser Designer konnte Templates aktualisieren, wann immer er wollte — neue Geräterahmen, aktualisierter Marketing-Text, saisonale Designs — ohne Entwicklerbeteiligung. Er aktualisierte das Template im visuellen Editor, und der nächste Pipeline-Lauf griff es automatisch auf.

Kunden-Onboarding

Einen neuen Whitelabel-Kunden hinzuzufügen ging von "2 Tage Designarbeit einplanen" zu "eine neue Template-Variante mit ihren Markenfarben und Logo erstellen". Die Pipeline erledigte den Rest.

Warum wir es verfügbar machen

Nachdem wir es intern genutzt und gesehen hatten, wie viel Zeit es sparte, realisierten wir, dass dieses Problem nicht einzigartig für uns war. Jeder App-Entwickler, der in den App Store oder Google Play ausliefert, hat mit Screenshot-Generierung zu tun. Whitelabel-Entwickler haben es am schlimmsten, aber selbst ein Einzelapp-Team mit Mehrsprachunterstützung steht vor dem gleichen Multiplikator-Problem.

Also haben wir es aufgeräumt, eine ordentliche API mit Dokumentation gebaut, einen Template-Editor hinzugefügt, den auch Nicht-Entwickler nutzen können, und es öffentlich gemacht. Wenn du Stunden damit verbringst, manuell App Store Screenshots zu erstellen, oder wenn deine Pipeline eine Lücke zwischen "Screenshots aufnehmen" und "in den Store hochladen" hat — Screenshots Live füllt diese Lücke.

Wir haben es gebaut, weil wir es brauchten. Wir teilen es, weil wir wissen, dass du es auch brauchst.