Über Screenshots.live
Screenshots.live automatisiert die Routinearbeit zwischen Mobile-Code und dem App Store. Entwickelt von einem Entwickler, der es leid war, dieselben Screenshots für 13 Sprachen bei jedem Release manuell neu zu exportieren.
Wer entwickelt das?
Eric Isensee — Founder
Entwickler mit Sitz in Deutschland. Baut Screenshots.live seit 2024 mit Fokus auf die API-Oberfläche, die Entwickler tatsächlich wollen — YAML-Konfigurationen, deterministische Renderings und CI/CD-freundliche Standardeinstellungen. Hat zuvor Mobile- und Backend-Systeme im E-Commerce, Fintech und Developer-Tooling ausgeliefert.
Warum gibt es Screenshots.live?
App-Store-Screenshots sind das wirkungsstärkste Marketing-Asset im Mobile-Bereich — sie entscheiden, ob ein Nutzer Ihre App installiert. Sie sind auch das arbeitsintensivste: Jedes Release bedeutet, dieselben Kompositionen für iPhone 6.5", iPhone 6.7", iPad 12.9", iPad 11", Android-Smartphone, Android 7"-Tablet und Android 10"-Tablet neu zu exportieren. Multiplizieren Sie das mit jeder Sprache, in der Sie veröffentlichen. Das sind 50+ Bilder pro Release für eine einsprachige App, 600+ für eine 12-sprachige App.
Manuelle Exporte zerbrechen unter dieser Last. Designer wechseln den Kontext. Sprachen geraten aus dem Takt. Releases verzögern sich. Screenshots.live löst das, indem Screenshots als Code behandelt werden: Einmal in einem visuellen Editor designen, programmgesteuert über eine API oder ein Fastlane-Plugin rendern, jede Variante in einem CI-Lauf ausliefern.
Für wen ist es gedacht?
- Mobile-Entwickler und Tech Leads, die möchten, dass Screenshot-Generierung in CI/CD lebt statt im Backlog eines Designers.
- ASO-Spezialisten, die A/B-Tests durchführen und Variantengenerierung benötigen, ohne Sketch+Photoshop-Akrobatik.
- Indie-Entwickler und kleine Teams, die in mehreren Sprachen ohne dediziertes Designteam veröffentlichen.
- Marketing-Teams in SaaS-Unternehmen, die Store-Assets mit Änderungen am Produkttext synchron halten müssen.
Wie entwickeln wir das?
Drei Prinzipien treiben das Produkt an:
- API-first. Jede Funktion des visuellen Editors ist auch als REST verfügbar. Vorlagen, Items, Renderings, Schriften — alle per API-Schlüssel adressierbar. Wenn ein Workflow im Editor gemacht werden kann, kann er auch in CI/CD gemacht werden.
- Deterministische Renderings. Dieselbe Vorlage + Variablen erzeugt jedes Mal dieselben Pixel. Keine instabilen LLM-Ausgaben im Render-Pfad. Entscheidend für diff-basierte Screenshot-Tests und überprüfbare CI-Artefakte.
- Sprach-Fan-out standardmäßig. Mehrsprachiges Rendering ist kein Feature-Flag — so funktioniert das Produkt. Eine Vorlage, jede unterstützte Sprache, in einem API-Aufruf.
Wo kann ich mehr erfahren?
- Lesen Sie den Leitfaden Build with AI für autonome Agenten-Workflows.
- Schauen Sie im Blog für ASO-Playbooks und Automatisierungs-Fallstudien vorbei.
- Durchstöbern Sie die Screenshot-Größen-Referenz 2026.