Perché Expo ha cambiato il modo in cui sviluppo app mobile

Ho costruito app mobile per più di un decennio. Per la maggior parte di quel tempo, sviluppo mobile significava una cosa sola: dolore. Due codebase, due linguaggi, due pipeline di deployment, e una macchina così seppellita tra Xcode e Android Studio che fare un git clone sembrava un piccolo miracolo.

React Native è stato un passo avanti — un linguaggio, due piattaforme. Ma il toolchain nativo era ancora lì, in agguato. Build di Gradle che fallivano per ragioni sepolte tre stack frame sotto in Java. L'inferno delle dipendenze CocoaPods. Un simulatore che si rifiutava di avviarsi finché non riavviavi il Mac.

Poi ho iniziato a usare Expo seriamente, e gran parte di quel dolore è semplicemente scomparso.

Cos'è davvero Expo

Expo non è un framework sopra React Native. È più simile a una piattaforma gestita — un insieme di strumenti, servizi e convenzioni che si occupano delle parti dello sviluppo mobile che non hanno nulla a che fare con il tuo prodotto.

La distinzione è importante. Quando costruisco Barba Studio, voglio pensare ai flussi di prenotazione e agli orari dei barbieri, non ai provisioning profile e ai permessi per le notifiche push. Expo mi permette di farlo.

OTA Updates: pubblicare senza l'App Store

Questa è la funzione che cambia tutto in produzione.

Con una app React Native standard, ogni aggiornamento passa per la revisione dell'app store. Bug fix? Pubblica, aspetta, spera. Con gli aggiornamenti OTA (over-the-air) di Expo — ora parte di EAS Update — invii un bundle JavaScript direttamente sui dispositivi degli utenti. Nessuna revisione. Nessuna attesa. Gli utenti ricevono la correzione alla prossima apertura dell'app.

Il limite è reale: non puoi distribuire modifiche al codice nativo in questo modo. Ma la maggior parte degli aggiornamenti — fix di UI, cambiamenti di logica, modifiche ai testi — è JavaScript puro. OTA le gestisce tutte istantaneamente.

Per uno sviluppatore solo che gestisce un prodotto in produzione, questa è la differenza tra un bug che dura tre giorni e uno che dura tre minuti.

EAS Build: la cloud build che funziona davvero

Prima di EAS Build, produrre un binario di release significava avere la versione giusta di Xcode sulla versione giusta di macOS, con i certificati giusti nel keychain giusto, con i provisioning profile giusti, tutti allineati nel giorno giusto della settimana.

EAS Build sposta l'intero processo sul cloud. Esegui eas build, aspetti, ottieni un binario. La tua macchina locale non ha bisogno di Xcode. Non ha bisogno di Android Studio. Non ha bisogno di niente di tutto ciò.

Sembra una cosa da poco finché non hai perso un pomeriggio a causa di un errore di code signing che si è rivelato essere un certificato scaduto. Dopo quella esperienza, le build cloud sembrano un regalo.

EAS Submit: un comando per entrambi gli store

Una volta che hai un binario, eas submit lo carica sull'App Store e su Google Play. Le credenziali sono salvate sui server di EAS — niente più gestione di chiavi API in file di ambiente locali o speranze che la macchina CI abbia il file JSON di Google Play montato da qualche parte.

L'intera pipeline — codice → build → submission — gira in una singola sessione senza toccare nessuna GUI.

L'esperienza di sviluppo quotidiana

Lo sviluppo giorno per giorno con Expo è veloce in un modo difficile da descrivere finché non lo hai vissuto. Expo Go ti permette di aprire la tua app su un dispositivo reale scansionando un QR code. I cambiamenti nel codice si riflettono istantaneamente tramite hot reload. Nessuno step di build. Nessun cavo. Nessun capriccio del simulatore.

Per app più complesse che richiedono moduli nativi personalizzati, c'è il development build — una versione custom di Expo Go costruita per il tuo progetto specifico. Lo costruisci una volta, lo esegui sul dispositivo, e da quel momento il ciclo di sviluppo interno è identico: veloce, hot, senza attrito.

Cosa perdi

Expo non va bene per ogni app. Se il tuo prodotto richiede una personalizzazione nativa profonda — pipeline camera personalizzate, periferiche Bluetooth, integrazioni di sistema strette — il workflow gestito prima o poi ti intralcerà.

Ma questa è una categoria ristretta. La maggior parte delle app — sistemi di prenotazione, funzionalità social, dashboard, flussi e-commerce — non ha mai bisogno di uscire dal layer gestito. E per quelle app, il compromesso è semplice: rinunci a un po' di controllo di basso livello in cambio di uno sviluppo significativamente più veloce e di una superficie molto più piccola di cose che possono andare storte.

Farei sempre quel compromesso.

Dodici anni dopo

Ho pubblicato la mia prima app mobile nel 2013. Java. Android SDK. Un emulatore che impiegava quattro minuti ad avviarsi e crashava all'arrivo. Ho visto l'ecosistema evolversi attraverso Swift, attraverso le prime beta di React Native, attraverso la lenta maturazione del toolchain.

Expo è la migliore esperienza di sviluppo mobile che ci sia mai stata. Non perfetta — niente lo è — ma genuinamente buona. Per uno sviluppatore solo che costruisce prodotti reali per utenti reali, "genuinamente buona" è più che sufficiente.

Se stai costruendo una nuova app React Native e non stai iniziando con Expo, chiediti perché. La via d'uscita è sempre disponibile se ne hai bisogno. La produttività che perdi mentre aspetti di averne bisogno non ti tornerà indietro.