2026-07-04 · Workflow · 9 min di lettura

Come creare screenshot App Store per un'app React Native (2026)

TL;DR. React Native non offre una pipeline screenshot ufficiale. Le opzioni concrete per catturare i frame grezzi sono Fastlane (XCUITest su iOS, screengrab/Espresso su Android), Detox (pensato per RN ed è il più semplice dei tre) o semplicemente la cattura manuale dal simulatore. Qualunque metodo tu scelga produce solo screenshot grezzi dell'app — trasformarli in un carosello pronto per lo store con didascalie, cornici del dispositivo e varianti localizzate è una fase di composizione marketing separata. Per la maggior parte dei team che rilascia poche volte all'anno, la cattura manuale più la composizione nel browser batte un'intera giornata di configurazione Fastlane.

Ecco la cosa che nessuno ti dice quando pubblichi la tua prima app React Native sull'App Store: non esiste un modo integrato per generare gli screenshot richiesti dallo store. Gli sviluppatori iOS nativi usano il registratore di UI test di Xcode; gli sviluppatori Android nativi hanno Espresso integrato nel build. React Native si appoggia su entrambi, con la logica dell'app che gira in JavaScript — e nessuno di quegli strumenti sa che il tuo JS esiste. Sei tu a dover colmare il divario.

Questo post illustra gli approcci che funzionano davvero nell'era della New Architecture (RN 0.7x e successivi, 2026), con comandi concreti. È onesto sui costi, perché ogni opzione ne ha uno reale. Poi tratta la parte che viene dopo la cattura — la composizione marketing e la localizzazione — che è un problema genuinamente separato indipendentemente da come ottieni i frame sorgente.

Il problema vero: nessuna pipeline ufficiale

App Store Connect vuole screenshot con dimensioni esatte in pixel, idealmente un set per classe di dispositivo e uno per ogni locale supportata. Google Play ha le sue dimensioni. Un progetto iOS nativo può guidare il simulatore tramite XCUITest e salvare i frame; React Native tecnicamente può farlo anche lui, ma il test che scrivi gira contro la shell nativa — il binario compilato — non direttamente contro i tuoi componenti JavaScript. Stai automatizzando una scatola nera che per caso renderizza il tuo JS.

Questa distinzione conta più di quanto sembri. Significa che la tua automazione degli screenshot si rompe per motivi che non c'entrano nulla con il tuo codice React (un bundler Metro non avviato, un simulatore bloccato su un dialogo di permessi, una build nativa che ha deviato dal tuo JS), e che la curva di apprendimento è quella di due framework di test nativi, non del tuo consueto stack RN. Ci sono tre modi seri per uscirne. Scegli in base alla frequenza con cui rilasci.

Opzione 1 — Fastlane snapshot (iOS) e screengrab (Android)

Fastlane è il framework di automazione mobile open source canonico, e i suoi moduli per gli screenshot sono l'opzione più collaudata. Sono anche quelli che richiedono più lavoro di configurazione per React Native, perché sono stati costruiti per progetti nativi e tollerano RN solo parzialmente.

iOS, tramite snapshot. Aggiungi un target di UI testing in Xcode e scrivi casi XCUITest in Swift che portano l'app a ogni schermata che vuoi catturare. fastlane snapshot init deposita uno Snapfile e un SnapshotHelper.swift nella cartella fastlane/. Nel test chiami setupSnapshot(app), avvii l'app e poi snapshot("01_home") a ogni stato. Lo esegui dal terminale con fastlane snapshot — non da dentro Xcode, che non produce l'output corretto. Scorre su ogni simulatore e locale configurati nello Snapfile e scrive i PNG in fastlane/screenshots/.

Il problema con React Native: snapshot avvia l'app compilata, che in debug ha bisogno che il bundler Metro sia già in esecuzione. Quindi il tuo Fastfile (o uno script wrapper) deve avviare Metro prima — il trucco comune è lanciare npx react-native start in una sessione tmux in background prima di chiamare snapshot, poi chiuderla dopo. Le build di release con il bundle JS già incorporato evitano questo problema, ma richiedono una build di release completa a ogni esecuzione.

Android, tramite screengrab. Framework completamente diverso: screengrab usa Espresso. Aggiungi chiamate Screengrab.screenshot("nome") nei test JUnit strumentati, dichiari i permessi (DISABLE_KEYGUARD, WAKE_LOCK, CHANGE_CONFIGURATION e permessi di storage), costruisci un APK di debug e un APK di test con ./gradlew assembleDebug assembleAndroidTest, ed esegui fastlane screengrab. L'output finisce in fastlane/metadata/android/. Come per iOS, Metro e l'emulatore devono essere già avviati — screengrab non li avvia per te.

Punti di forza:

Integrato con CI e sempre aggiornato. Collegalo alla tua pipeline e gli screenshot si rigenerano a ogni build di release, sempre allineati all'app reale.
Rendering per locale reale. Ogni locale gira nel simulatore/emulatore con le sue impostazioni di locale effettive, quindi date, numeri e valute si renderizzano nativamente — non simulate in uno strumento di design.
Gratuito, open source, maturo. Nessun abbonamento, community vasta, modalità di fallimento ben documentate.

Punti deboli (sii onesto con te stesso):

Devi mantenere due suite di test native. XCUITest in Swift per iOS, Espresso/JUnit in Kotlin/Java per Android — per uno sviluppatore RN potrebbero essere due stack sconosciuti.
Testa la shell nativa, non la logica JS. I test verificano le viste native renderizzate; non conoscono il tuo albero di componenti.
Il setup richiede uno o due giorni la prima volta, e il problema ricorrente con il bundler Metro è una fonte costante di run CI instabili.
L'output sono frame grezzi. Nessuna didascalia, nessuna cornice del dispositivo, nessun gradiente, nessun carosello — solo la UI grezza dell'app alla risoluzione del simulatore.
Mac obbligatorio per iOS. Il simulatore richiede Xcode.

Per un confronto approfondito specificamente sulla questione della composizione, consulta Fastlane snapshot vs screenshot App Store no-code e il confronto Mokbi vs Fastlane.

Opzione 2 — Screenshot con Detox (pensato per React Native)

Detox è un framework di test end-to-end a scatola grigia creato appositamente per React Native dal team di Wix. Se già usi Detox per i test e2e, gli screenshot sono quasi gratuiti, e la curva di apprendimento è quella che vorresti comunque affrontare — è una JavaScript API, non Swift o Kotlin.

La chiamata di cattura è una sola riga all'interno di qualsiasi test:

// full screen
const path = await device.takeScreenshot('01_home');

// a single element
await element(by.id('paywallRoot')).takeScreenshot('paywall');

Se quelle immagini vengono conservate come artefatti dipende dal flag --take-screenshots (none, failing, manual o all) e dalla configurazione in .detoxrc.js. In modalità manual o all, i test superati scrivono in <artifacts-location>/✓ [test name]/[name].png. Guidi l'app a ogni stato con gli stessi matcher Detox che useresti per le asserzioni, poi esegui lo snapshot.

Punti di forza:

È una JavaScript API. Scrivi i test nel linguaggio in cui è scritta la tua app — nessuna suite di test nativa in un secondo linguaggio da gestire.
A scatola grigia, quindi capisce RN. Detox si sincronizza con il bridge/JSI dell'app e aspetta che sia inattiva, il che rende gli screenshot molto meno instabili rispetto ai tempi ciechi di XCUITest.
Un solo framework, entrambe le piattaforme. Lo stesso file di test cattura iOS e Android.
Probabilmente ce l'hai già se fai test e2e — in quel caso il costo marginale degli screenshot è minimo.

Punti deboli:

Avviare Detox da zero non è banale — configurazione del build nativo, un build di test dedicato e configurazione di emulatore/simulatore. Se non lo usi già, è un investimento reale.
La gestione delle locale è a tuo carico. Detox non scorre automaticamente su tutte le locale dell'App Store come fa lo Snapfile di snapshot; devi scrivere tu i cambi di locale o rieseguire con impostazioni diverse.
L'output sono ancora frame grezzi. Come Fastlane — sola UI grezza dell'app, nessuno strato marketing.
Gli screenshot possono variare tra macchine diverse (un problema noto di Detox), il che conta se li confronti in CI ma è irrilevante per gli asset dello store.

Opzione 3 — Cattura manuale (la più semplice, e sottovalutata)

Apri il simulatore iOS o un emulatore Android, porta la tua app a ogni schermata a mano e cattura il frame. Su iOS, Cmd-S nel simulatore salva un PNG correttamente dimensionato sul desktop; xcrun simctl io booted screenshot home.png fa lo stesso dal terminale ed è facile da integrare in script leggeri. Su Android, il pulsante fotocamera dell'emulatore o adb exec-out screencap -p > home.png cattura lo schermo. Funziona anche un dispositivo fisico — cattura, poi trasferisci i file via AirDrop o cavo.

Viene scartato troppo in fretta. Ha configurazione zero, non si rompe mai in CI perché non c'è CI, e per un'app che rilascia una manciata di volte all'anno è davvero il percorso più rapido per ottenere un set di frame sorgente. Il lato negativo è ovvio e reale: è manuale, quindi non si rigenera da solo, e se cambi una schermata le tue catture diventano obsolete finché non le rifai. Per un carosello di cinque schermate sono dieci minuti di lavoro per release — meno costoso che mantenere un'automazione di test che esegui due volte all'anno.

La parte che tutti dimenticano: composizione e localizzazione

Ecco cosa accomuna tutte e tre le opzioni: ognuna produce screenshot grezzi dell'app, e gli screenshot grezzi non sono quelli che convertono nello store. Il carosello App Store che muove davvero le installazioni ha una cornice del dispositivo attorno allo schermo, una didascalia di una riga che spiega il beneficio, uno sfondo che non è il bianco della tua app e continuità tra i cinque pannelli. Nessuno degli strumenti di cattura sopra produce niente di tutto ciò — si fermano al frame grezzo. Non è un difetto loro; è un lavoro diverso.

È qui che si inserisce Mokbi, e vale la pena essere precisi sul confine: non cattura i tuoi screenshot sorgente — quello lo fa il simulatore, il dispositivo o Fastlane/Detox di cui sopra. Quello che fa è lo strato di composizione marketing e localizzazione che viene dopo. Trascini i tuoi frame grezzi nell'editor nel browser, li avvolgi in cornici del dispositivo reali, aggiungi didascalie, componi caroselli multi-pannello, poi con un clic traduci le didascalie in 50 lingue ed esporti in batch a ogni dimensione richiesta dagli store. Progettare è gratuito con anteprima con watermark; l'esportazione illimitata senza watermark e la pubblicazione arrivano con un abbonamento — Solo €29.99/mo (1 app) o Studio €49.99/mo (fino a 5 app), nessun acquisto una tantum. Il motivo per cui si integra bene è che risolve il problema che la tua pipeline di cattura non affronta nemmeno: trasformare una cartella di PNG in un carosello localizzato e pronto per lo store senza aprire Photoshop né ridimensionare a mano per 50 lingue.

Il workflow combinato realistico

Cattura i frame sorgente. Scegline uno: Fastlane (snapshot + screengrab) in CI per rilasci frequenti, Detox se hai già i test e2e, oppure cattura manuale dal simulatore per rilasci occasionali. Output: una cartella di PNG grezzi per schermata, per dispositivo.
Componi, aggiungi didascalie e cornici. Trascina i frame grezzi nell'editor nel browser. Aggiungi cornici del dispositivo, scrivi le didascalie con il beneficio, costruisci il carosello a cinque pannelli, scegli uno sfondo.
Traduci. Con un clic, traduci in batch le didascalie in 50 lingue, poi controlla a mano le lingue che ti interessano di più.
Esporta in batch. Esporta ogni locale a ogni dimensione richiesta per App Store Connect e Google Play in un'unica operazione.
Sostituisci al prossimo rilascio. Ricattura i frame modificati (riesegui Fastlane/Detox o catturali a mano), riapri il progetto salvato, sostituisci gli screenshot, riesporta. Il lavoro di didascalie e traduzione è già fatto.

Quando puoi saltare l'automazione

Se rilasci da uno a tre volte all'anno — il che descrive la maggior parte delle app React Native indie — il costo di setup di Fastlane o Detox quasi non si ripaga mai. Spenderesti una giornata a configurare XCUITest e il problema con il bundler Metro per risparmiare dieci minuti di cattura manuale due volte all'anno. I conti non tornano. Cattura a mano dal simulatore, componi e localizza nel browser, e hai finito in meno tempo totale di quanto ci vorrà per configurare una volta l'automazione.

L'automazione si ripaga quando rilasci ogni settimana o ogni giorno, quando il disallineamento degli screenshot diventa un bug ricorrente, o quando gestisci un portfolio di app e il costo di cattura per app si moltiplica. A quella scala, Fastlane in CI (o Detox se è già nel tuo stack) è la scelta giusta per la fase di cattura — e lo abbini comunque a uno strumento di composizione nel browser per lo strato marketing, perché nessuna pipeline di cattura produce un carosello finito.

Prima di esportare qualsiasi cosa, vale la pena verificare gli obiettivi: le dimensioni degli screenshot App Store che devi effettivamente caricare e i requisiti degli screenshot App Store che fanno respingere le submission. Farlo bene una volta evita un andata-e-ritorno con App Review.

Cosa leggere dopo

Apri l'editor →