À propos de Screenshots.live
Screenshots.live automatise les tâches répétitives entre le code mobile et l'App Store. Conçu par un développeur lassé de réexporter manuellement les mêmes captures d'écran pour 13 langues à chaque mise en production.
Qui le construit ?
Eric Isensee — Founder
Ingénieur basé en Allemagne. Construit Screenshots.live depuis 2024 en se concentrant sur la surface API que les développeurs souhaitent réellement — configurations YAML, rendus déterministes et valeurs par défaut adaptées au CI/CD. A précédemment livré des systèmes mobiles et backend dans l'e-commerce, la fintech et l'outillage pour développeurs.
Pourquoi Screenshots.live existe-t-il ?
Les captures d'écran sur les stores sont l'actif marketing à plus fort effet de levier dans le mobile — elles déterminent si un utilisateur installe votre application. Elles sont aussi les plus laborieuses : chaque mise en production implique de réexporter les mêmes compositions pour iPhone 6.5", iPhone 6.7", iPad 12.9", iPad 11", téléphone Android, tablette Android 7" et tablette Android 10". Multipliez par chaque langue dans laquelle vous publiez. Cela représente plus de 50 images par mise en production pour une application monolingue, plus de 600 pour une application en 12 langues.
Les exports manuels craquent sous cette charge. Les designers changent constamment de contexte. Les langues se désynchronisent. Les mises en production prennent du retard. Screenshots.live résout ce problème en traitant les captures d'écran comme du code : concevez une fois dans un éditeur visuel, rendez par programmation via une API ou un plugin Fastlane, livrez chaque variante en une seule exécution CI.
À qui s'adresse-t-il ?
- Développeurs mobiles et tech leads qui veulent que la génération de captures d'écran vive dans le CI/CD plutôt que dans le backlog d'un designer.
- Spécialistes ASO qui mènent des tests A/B et ont besoin d'une génération de variantes sans acrobaties Sketch+Photoshop.
- Développeurs indépendants et petites équipes qui livrent dans plusieurs langues sans équipe de design dédiée.
- Équipes marketing chez les entreprises SaaS qui doivent maintenir les actifs des stores en phase avec les changements de copy produit.
Comment construisons-nous cela ?
Trois principes guident le produit :
- API-first. Chaque capacité de l'éditeur visuel est également exposée en REST. Modèles, éléments, rendus, polices — tout est adressable par clé API. Si un flux de travail peut être réalisé dans l'éditeur, il peut l'être dans le CI/CD.
- Rendus déterministes. Le même modèle + variables produit les mêmes pixels à chaque fois. Aucune sortie LLM instable dans le chemin de rendu. Essentiel pour les tests de captures d'écran basés sur des diffs et les artefacts CI revus.
- Multiplexage par langue par défaut. Le rendu multi-langue n'est pas un feature flag — c'est ainsi que fonctionne le produit. Un modèle, toutes les langues prises en charge, en un seul appel API.
Où puis-je en apprendre davantage ?
- Lisez le guide Build with AI pour les flux de travail d'agents autonomes.
- Consultez le blog pour les playbooks ASO et les études de cas d'automatisation.
- Parcourez la référence des tailles de captures d'écran 2026.