Screenshot App Store con Expo: perché EAS Submit non li gestisce e come farlo in fretta (2026)

Se pubblichi un'app Expo, il tuo percorso di rilascio probabilmente si conclude con una sola riga: eas submit. Prende la build prodotta da EAS e la consegna ad Apple o Google. Pulito, senza sorprese, affidabile. Poi apri App Store Connect per rendere la build live e — gli slot degli screenshot sono vuoti. Ogni volta.

Questo coglie di sorpresa molte persone perché EAS dà l'impressione di fare tutto. Compila, firma, invia. Sicuramente gestisce anche gli screenshot? Non è così, e la documentazione lo dice chiaramente. Non è un bug né una funzionalità mancante su cui fare segnalazione — è semplicemente fuori dall'ambito di EAS Submit.

Cosa fa davvero EAS Submit (e cosa non fa)

EAS Submit è un servizio di consegna dei binari. Carica esattamente una cosa: il tuo archivio compilato — un .ipa per iOS, un .aab per Android — nella pipeline di elaborazione dello store. La documentazione Expo è esplicita sul confine:

"EAS Submit carica il tuo binario ma non gestisce i metadati della scheda store, gli screenshot né le note di rilascio."

Esiste uno strumento gemello, EAS Metadata, che può automatizzare parti della scheda App Store — nome dell'app, sottotitolo, descrizioni localizzate, parole chiave, URL di supporto — da un file di configurazione. È genuinamente utile e vale la pena configurarlo. Ma leggi attentamente il suo ambito: gli screenshot non ci sono. EAS Metadata invia testo, non immagini. I tuoi screenshot, su entrambi gli store, sono ancora a tuo carico da produrre e caricare.

Il problema degli screenshot con Expo si divide quindi in due lavori distinti, ed è utile tenerli separati nella testa:

1. Cattura — ottenere i frame grezzi delle schermate reali dell'app da una build.
2. Composizione e localizzazione — trasformare quei frame grezzi nei pannelli marketing con cornice, didascalia e versioni multilingue che gli store mostrano effettivamente.

EAS non fa nessuno dei due. La guida agli asset store di Expo ti rimanda a catturare i frame da solo e a progettare i pannelli in uno strumento come Figma. Vediamo entrambi i lavori con comandi concreti.

Lavoro 1: catturare i frame da una build dev o preview

Vuoi screenshot dell'app vera, quindi hai bisogno che l'app giri da qualche parte dove puoi catturarla. Per Expo questo significa un dev client o una build preview — non Expo Go, perché Expo Go mostra l'interfaccia wrapper di Expo e la tua configurazione nativa potrebbe differire. Compila ed esegui in locale con i comandi Expo standard:

• npx expo run:ios — effettua il prebuild nativo iOS, compila e avvia la tua app nel simulatore iOS.
• npx expo run:android — lo stesso per un emulatore Android (o un dispositivo connesso).

Con l'app visibile nel simulatore iOS, la cattura è un singolo comando dal terminale Mac:

xcrun simctl io booted screenshot home.png

booted punta al simulatore in esecuzione e scrive un PNG pixel-perfetto nella tua directory di lavoro. Due flag contano per il lavoro sullo store: --type=png (il default, quello che gli store vogliono) e --mask=ignored versus --mask=black — la maschera controlla se la tacca e gli angoli arrotondati vengono renderizzati nell'immagine. Per i caricamenti sull'App Store di solito vuoi i pixel rettangolari piatti, poi aggiungi la cornice del dispositivo in fase di composizione, quindi la cattura senza maschera è generalmente il punto di partenza giusto.

Su Android, cattura direttamente dall'emulatore (o dal dispositivo) con adb:

adb exec-out screencap -p > home.png

Usa exec-out, non shell screencap. Il percorso shell semplice convoglia il PNG attraverso uno pseudo-terminale che manomette il binario in alcune configurazioni (ottieni un file corrotto con ritorni a capo spuri); exec-out trasmette i byte direttamente ed è la forma affidabile. Se esegui più emulatori, puntane uno con adb -s <serial> ottenuto da adb devices.

Questo è tutto il toolkit di cattura manuale: due comandi, uno per piattaforma, nessuna dipendenza oltre a Xcode e l'Android SDK che hai già per una build nativa Expo.

Lavoro 1, automatizzato: Maestro o Detox

Navigare a mano fino alla schermata giusta ed eseguire quei comandi è ragionevole per una manciata di scatti. Quando hai otto schermate su due classi di dispositivo, o vuoi screenshot rigenerati a ogni rilascio perché non divergano mai dall'interfaccia reale, automatizzi la cattura con uno strumento di test end-to-end capace di guidare l'app e scattare i frame.

Maestro è quello a cui Expo stessa ricorre negli esempi documentati di EAS Workflows. I flow sono in YAML semplice, il che mantiene bassa la barriera d'ingresso. Un flow che porta a una schermata e la cattura si presenta così:

appId: com.you.yourapp --- - launchApp - tapOn: "Get started" - assertVisible: "Your dashboard" - takeScreenshot: dashboard

Eseguilo con maestro test flows/home.yaml. Il comando takeScreenshot scrive un PNG nella directory di output dei test (imposta MAESTRO_TESTS_DIR dove vuoi che finiscano gli asset). Gli stessi flow girano in CI su EAS Workflows — l'esempio documentato da Expo compila un .apk con un profilo di build e2e-test e poi esegue un flow .maestro/ su di esso — così puoi collegare la cattura degli screenshot allo stesso job che esegue la suite e2e.

Detox è l'altra opzione consolidata, con un'API JavaScript più rigorosa e programmatica:

const path = await device.takeScreenshot('dashboard');

Sii onesto con te stesso riguardo al setup Detox con Expo, però. Detox non supporta ufficialmente Expo. In pratica funziona se esegui npx expo prebuild per generare i progetti nativi e compili un client in stile release (non un dev client) in modo che il bundle JS sia incorporato — poi punti Detox a quel binario. Ha più parti mobili rispetto al YAML di Maestro, e il vantaggio è la sincronizzazione più rigorosa e l'API di asserzione di Detox. Se usi già Detox, riusalo per la cattura; se stai scegliendo da zero e il tuo obiettivo sono gli screenshot per lo store, Maestro è il percorso più leggero.

Lavoro 1, manuale: la scelta giusta per rilasci poco frequenti

L'automazione si ripaga quando rilasci spesso. Se fai da uno a tre rilasci all'anno — il che descrive la maggior parte delle app Expo indie — configurare flow Maestro o una config Detox per la cattura degli screenshot è un lavoro che paghi una volta e ammortizzi a malapena. Per quella cadenza, fai semplicemente:

1. Avvia la build con npx expo run:ios / run:android, popolala con dati demo realistici.
2. Naviga a mano a ogni schermata principale.
3. Cattura ognuna con il comando simctl / adb sopra.

Venti minuti di clic battono mezza giornata di test harness che avrai dimenticato come manutenere al prossimo rilascio. Non c'è niente di cui vergognarsi nella cattura manuale — gli store non possono sapere come è stato prodotto il PNG.

Lavoro 2: composizione e localizzazione in 50 lingue

Questa è la parte che gli strumenti di cattura non toccano deliberatamente, ed è quella su cui gli store ti giudicano davvero. Un PNG grezzo di simctl è l'interfaccia della tua app su sfondo bianco. Quello che si posiziona nelle ricerche e converte sulla pagina prodotto è il pannello marketing: lo screenshot dentro una cornice del dispositivo, su uno sfondo brandizzato, con una didascalia di una riga che spiega perché quella schermata è importante — di solito come un carosello multi-pannello che si legge da sinistra a destra. E sull'App Store, gli screenshot sono localizzati per classe di dispositivo e per lingua, quindi un lancio serio è decine di varianti, non cinque.

Questo è lo spazio delimitato dove si inserisce Mokbi, e vale la pena essere precisi sul confine. Mokbi non cattura la tua app — i frame sorgente li produci ancora tu con i comandi Expo sopra. Quello che fa è prendere quei frame e permetterti, nel browser: inserirli in cornici reali del dispositivo, aggiungere didascalie e sfondi a gradiente, comporre caroselli multi-pannello, tradurre con un clic il testo delle didascalie in 50 lingue ed esportare in batch ogni dimensione App Store e Play Store. Progetti gratis con un'anteprima con watermark; l'esportazione illimitata arriva con un abbonamento — Solo €29.99/mo (1 app) o Studio €49.99/mo (fino a 5 app), senza acquisto una tantum. Sostituisce la fase con i modelli Figma a cui la guida Expo accenna brevemente — niente di più, niente di meno.

Il workflow combinato realistico

1. Compila un client dev/preview. npx expo run:ios e npx expo run:android, popolati con buoni dati demo.
2. Cattura i frame sorgente. Manualmente via xcrun simctl io booted screenshot e adb exec-out screencap -p, oppure in modo automatizzato via Maestro takeScreenshot / Detox device.takeScreenshot — idealmente su EAS Workflows così si rigenerano a ogni rilascio.
3. Componi i pannelli marketing. Inserisci in cornice, aggiungi didascalie e disponi il carosello a partire da quei frame grezzi.
4. Localizza ed esporta in batch. Traduci le didascalie nelle lingue target, esporta ogni dimensione richiesta per entrambi gli store.
5. Carica gli asset della scheda. Screenshot su App Store Connect e Play Console; abbina EAS Metadata per i campi di testo se lo usi.
6. Invia il binario. eas submit — l'unico passo di cui EAS è davvero responsabile.
7. Al prossimo rilascio: ricattura le schermate modificate, riapri il progetto di composizione salvato, sostituisci i frame, riesporta. Didascalie e traduzioni rimangono al loro posto.

Quando puoi saltare l'automazione

Ricorri a Maestro o Detox per la cattura quando il disallineamento degli screenshot è un costo reale: rilasci ogni settimana, l'interfaccia cambia continuamente, o gestisci molte app e non puoi permetterti immagini store obsolete. In quei casi i frame rigenerati in CI si ripagano da soli e la storia del tooling per screenshot React Native (di cui Expo eredita le stesse logiche) vale l'investimento.

Per tutti gli altri — chi rilascia una volta al trimestre — saltala. La cattura manuale con due comandi da terminale, poi composizione e localizzazione nel browser, ti porta a una scheda multilingue rifinita in un pomeriggio senza nulla da manutenere tra un rilascio e l'altro. Adatta il tooling alla tua cadenza, non a ciò che sembra impressionante su un dashboard CI.

In ogni caso, la metà binaria è risolta: eas submit se ne occupa. Assicurati di verificare i tuoi screenshot rispetto ai requisiti aggiornati dello store prima di caricarli — Apple respinge una scheda per un singolo pixel fuori posto — e il resto del lancio è solo design.

Cosa leggere dopo

• Per sviluppatori Expo
• Screenshot App Store con React Native
• Confronto: Mokbi vs Fastlane
• Dimensioni screenshot App Store
• Requisiti screenshot App Store

Apri l'editor →