Chi siamo: Screenshots.live
Screenshots.live automatizza il lavoro ripetitivo tra il codice mobile e l'App Store. È stato creato da uno sviluppatore stanco di riesportare manualmente gli stessi screenshot per 13 lingue ad ogni release.
Chi c'è dietro al progetto?
Eric Isensee — Founder
Ingegnere con sede in Germania. Sviluppa Screenshots.live dal 2024, concentrandosi sulla superficie API che gli sviluppatori desiderano davvero: configurazioni YAML, render deterministici e impostazioni predefinite ottimizzate per CI/CD. In passato ha realizzato sistemi mobile e backend nei settori e-commerce, fintech e strumenti per sviluppatori.
Perché esiste Screenshots.live?
Gli screenshot dell'App Store sono la risorsa di marketing con la maggiore leva nel mobile: decidono se un utente installerà o meno la sua app. Sono anche le risorse che richiedono più lavoro: ogni release significa riesportare le stesse composizioni per iPhone 6.5", iPhone 6.7", iPad 12.9", iPad 11", smartphone Android, tablet Android 7" e tablet Android 10". Moltiplichi il tutto per ogni lingua in cui pubblica. Sono oltre 50 immagini per release per un'app monolingua e oltre 600 per un'app in 12 lingue.
Le esportazioni manuali non reggono questo carico. I designer perdono concentrazione. Le lingue si disallineano. Le release slittano. Screenshots.live risolve tutto questo trattando gli screenshot come codice: progetti una volta sola in un editor visuale, esegua il rendering programmaticamente tramite un'API o un plugin Fastlane, pubblichi tutte le varianti in una singola esecuzione di CI.
A chi è rivolto?
- Sviluppatori mobile e tech lead che vogliono che la generazione degli screenshot avvenga in CI/CD anziché finire nel backlog di un designer.
- Specialisti ASO che eseguono test A/B e necessitano di una generazione di varianti senza dover ricorrere a virtuosismi tra Sketch e Photoshop.
- Sviluppatori indie e piccoli team che pubblicano in più lingue senza un team di design dedicato.
- Team marketing di aziende SaaS che devono mantenere allineati gli asset dello store con le modifiche al copy del prodotto.
Come sviluppiamo il prodotto?
Tre principi guidano il prodotto:
- API-first. Ogni funzionalità dell'editor visuale è esposta anche come REST. Template, item, render, font: tutto è indirizzabile tramite API key. Se un flusso di lavoro può essere svolto nell'editor, può essere svolto anche in CI/CD.
- Render deterministici. Lo stesso template con le stesse variabili produce sempre gli stessi pixel. Nessun output instabile da LLM nel percorso di rendering. Fondamentale per i test di screenshot basati su diff e per artefatti di CI verificabili.
- Fan-out tra lingue di default. Il rendering multilingua non è un feature flag, è il modo in cui funziona il prodotto. Un solo template, tutte le lingue supportate, in una singola chiamata API.
Dove può approfondire?
- Legga la guida Build with AI per i flussi di lavoro con agenti autonomi.
- Consulti il blog per playbook ASO e case study di automazione.
- Sfogli il riferimento alle dimensioni degli screenshot 2026.