EAS Build & Submit: Deploy React Nativ…

Pubblicare un'app React Native nel 2026 non è più il processo manuale, frammentato e fragile che era qualche anno fa. EAS Build e EAS Submit — i servizi cloud di Expo — hanno trasformato il deployment in una pipeline integrata: build native in cloud, gestione automatica dei certificati, submission diretta su App Store e Play Store, OTA updates e workflow CI/CD, tutto orchestrato da una singola CLI.

Onestamente, dopo aver passato anni con Fastlane, script shell e fogli Excel pieni di versioni, vedere una build production partire con un solo comando è ancora una piccola soddisfazione. E sì, in questa guida ti porto passo-passo dalla configurazione iniziale alla pubblicazione sui due store principali, con eas.json pronti all'uso, profili di build, automazione via EAS Workflows e un po' di troubleshooting per i problemi che (prima o poi) incontrerai.

Perché EAS è lo standard di deployment nel 2026

Con Expo SDK 53+ e React Native 0.79+ la piattaforma EAS è ormai matura, e si sente. Negli ultimi due anni l'ecosistema mobile ha cambiato passo: i cicli di rilascio si sono compressi, Apple e Google hanno introdotto requisiti più rigidi su privacy manifests, dichiarazioni SDK e firma del codice. Le release devono raggiungere gli utenti in ore, non settimane.

EAS risponde a queste esigenze unificando tutto in un'unica piattaforma:

EAS Build: build native iOS e Android in cloud, anche per progetti bare workflow.
EAS Submit: upload automatico su App Store Connect e Google Play Console.
EAS Update: aggiornamenti Over-The-Air (OTA) per il bundle JavaScript.
EAS Workflows: pipeline CI/CD native, alternativa a GitHub Actions per scenari mobile.
EAS Hosting: hosting per Expo Router web e API routes.
EAS Metadata e EAS Insights: gestione metadata degli store e analytics.

Il vantaggio decisivo rispetto a soluzioni come Fastlane o Bitrise è l'integrazione nativa con il modulo expo-updates: profili di build, channel OTA e runtime version sono collegati a livello di configurazione. Questo elimina intere classi di errori — quelli silenziosi, che ti accorgi di avere solo quando un utente segnala che l'update non arriva.

Prerequisiti e account necessari

Prima di iniziare, assicurati di avere:

Un account Expo gratuito (registrazione su expo.dev): consente l'accesso al piano Free di EAS Build, con 15 build Android + 15 build iOS al mese.
Un Apple Developer Program account ($99/anno) per distribuire su App Store.
Un Google Play Developer account ($25 una tantum) per distribuire su Play Store.
Node.js 20 o superiore e npm oppure pnpm.
Un progetto React Native — Expo managed o bare workflow, indifferentemente.

I piani EAS nel 2026

Expo ha consolidato un modello di pricing basato sul consumo, con quattro piani principali:

Free ($0/mese): 15 build Android + 15 build iOS, 1.000 MAU per EAS Update, 100 GiB di bandwidth.
Starter ($19/mese): $45 di build credit, 3.000 MAU.
Production ($199/mese): $225 di build credit, 50.000 MAU, concurrency aumentata.
Enterprise (custom): build dedicate, supporto prioritario, SLA.

Oltre i limiti del piano, il billing è pay-as-you-go. Le notifiche email arrivano all'80% e al 100% del credito incluso, così puoi anticipare gli sconfinamenti (cosa che, fidati, succede sempre il giorno prima di una demo importante).

Installazione e configurazione di EAS CLI

Il primo passo è installare la CLI globalmente e autenticarsi:

npm install -g eas-cli
eas login
eas whoami

Poi, nella root del progetto, esegui il comando di configurazione iniziale:

cd my-react-native-app
eas init
eas build:configure

Il comando eas build:configure genera due cose fondamentali:

eas.json — la configurazione dei profili di build e submit.
Aggiorna app.json con un campo extra.eas.projectId che lega il progetto locale al progetto su expo.dev.

Strutturare eas.json: build profiles in produzione

Il cuore di EAS è il file eas.json. Una configurazione ben pensata usa extends per evitare duplicazione e separa nettamente gli ambienti. Ecco un esempio production-ready per il 2026:

{
  "cli": {
    "version": ">= 14.0.0",
    "appVersionSource": "remote"
  },
  "build": {
    "base": {
      "node": "20.18.0",
      "env": {
        "EXPO_NO_TELEMETRY": "1"
      }
    },
    "development": {
      "extends": "base",
      "developmentClient": true,
      "distribution": "internal",
      "channel": "development",
      "env": {
        "APP_ENV": "development",
        "API_URL": "https://dev-api.example.com"
      },
      "ios": { "simulator": true },
      "android": { "buildType": "apk" }
    },
    "preview": {
      "extends": "base",
      "distribution": "internal",
      "channel": "preview",
      "env": {
        "APP_ENV": "preview",
        "API_URL": "https://staging-api.example.com"
      },
      "ios": {
        "resourceClass": "m-medium",
        "simulator": false
      },
      "android": { "buildType": "apk" }
    },
    "production": {
      "extends": "base",
      "channel": "production",
      "autoIncrement": true,
      "env": {
        "APP_ENV": "production",
        "API_URL": "https://api.example.com"
      },
      "ios": {
        "resourceClass": "m-large"
      },
      "android": {
        "buildType": "app-bundle"
      }
    }
  },
  "submit": {
    "production": {
      "ios": {
        "appleId": "[email protected]",
        "ascAppId": "1234567890",
        "appleTeamId": "ABCD123456"
      },
      "android": {
        "serviceAccountKeyPath": "./google-service-account.json",
        "track": "production",
        "releaseStatus": "draft"
      }
    }
  }
}

Vediamo i punti chiave di questa configurazione:

appVersionSource: "remote": la versione build è gestita da EAS, non più manualmente in app.json. Addio conflitti di versione tra developer (questa, da sola, vale l'adozione).
autoIncrement: true: auto-incrementa il buildNumber iOS e il versionCode Android a ogni produzione.
channel: lega il profilo a un canale EAS Update, fondamentale per le OTA.
resourceClass: per progetti grandi, m-large riduce sensibilmente i tempi di build iOS.
buildType: "app-bundle": obbligatorio per Play Store (AAB), apk per la distribuzione interna.

Gestione dei credentials: keystore e provisioning

EAS può gestire automaticamente keystore Android, provisioning profile iOS e distribution certificate, oppure puoi fornirli tu. Per la maggior parte dei team la gestione automatica è preferibile: è sicura, persistente ed elimina la classica catastrofe del "ho perso il keystore" (chiunque abbia gestito un'app per qualche anno sa di cosa parlo).

Android: generazione del keystore

Alla prima esecuzione di una build production, EAS chiederà:

eas build --platform android --profile production

? Generate a new Android Keystore? (Y/n)

Rispondendo Y, EAS genera e archivia il keystore in modo sicuro sui propri server. Puoi sempre scaricarlo per backup:

eas credentials

iOS: certificati e provisioning profile

Per iOS, EAS si collega all'Apple Developer Portal. Bastano le credenziali Apple ID (con 2FA) e un App Specific Password o, ancora meglio, un Apple API Key con scope da App Store Connect:

eas credentials
# scegli iOS production Add new

# in alternativa, configura la API Key:
# https://appstoreconnect.apple.com/access/api

L'API Key è preferibile in CI/CD perché non richiede 2FA interattivo. Anche solo per questo, vale la pena passarci una volta per tutte.

La prima build di sviluppo

Il development build è la sostituzione moderna di Expo Go: include il dev client di Expo ma con tutte le dipendenze native del tuo progetto. Lo crei una sola volta e ci sviluppi sopra a ogni hot reload, senza dover ricompilare ad ogni modifica di codice nativo.

# build per simulatore iOS
eas build --platform ios --profile development

# build APK per device/emulatore Android
eas build --platform android --profile development

# entrambe le piattaforme in parallelo
eas build --platform all --profile development

Al termine ricevi un URL: scansiona il QR dal device, installa il dev client, e npx expo start --dev-client serve il bundle. Da qui in poi sviluppi normalmente — solo le modifiche al codice nativo richiedono una nuova build.

Build di produzione e distribuzione interna

Per condividere una preview con stakeholder o tester interni:

eas build --platform all --profile preview

Con "distribution": "internal" il risultato è:

Un APK Android scaricabile via URL e installabile su qualsiasi device.
Un IPA iOS firmato come ad-hoc, installabile solo sui device il cui UDID è registrato nell'Apple Developer Portal.

EAS gestisce automaticamente la registrazione di nuovi UDID iOS tramite il comando eas device:create. Comodo, soprattutto quando un PM ti chiede di installare l'app sul suo iPad alle 22.

Per la build di produzione finale, destinata agli store:

eas build --platform all --profile production --auto-submit

Il flag --auto-submit innesca eas submit automaticamente al termine della build, usando i parametri della sezione submit.production del tuo eas.json.

EAS Submit: pubblicazione sugli store

Apple App Store con TestFlight

Dopo la prima build production, esegui:

eas submit --platform ios --profile production --latest

Il flag --latest usa l'ultima build riuscita. EAS carica l'IPA su App Store Connect e, pochi minuti dopo, la build appare in TestFlight, dove può essere distribuita ai beta tester interni o esterni.

Per la submission finale alla review pubblica, devi compilare i metadata (descrizione, screenshot, privacy policy) su App Store Connect — oppure usare EAS Metadata per gestirli come codice:

eas metadata:pull
# modifica store.config.json
eas metadata:push

Google Play Store: la prima volta è manuale

Per il Play Store c'è un vincolo fastidioso: il primo upload deve essere manuale, è una limitazione della Play Console API. Quindi:

Crea l'app su play.google.com/console.
Esegui eas build --platform android --profile production.
Scarica l'AAB dal dashboard EAS e caricalo manualmente nella traccia "Internal testing".
Crea un Google Service Account con ruolo Release Manager e scarica la JSON key.
Salva il file come google-service-account.json nella root del progetto (e aggiungilo a .gitignore, mi raccomando).

Da quel momento in poi, tutte le submission sono automatizzate:

eas submit --platform android --profile production --latest

Il parametro "track" in eas.json determina su quale traccia rilasciare (internal, alpha, beta, production). Per release graduali, "releaseStatus": "draft" evita pubblicazioni immediate.

EAS Update: OTA updates senza store review

Una delle leve più potenti di EAS è la possibilità di pushare modifiche JavaScript senza passare dalla review degli store. Questo include bug fix, hotfix di UI, contenuti dinamici — tutto ciò che non tocca il codice nativo.

Setup minimo:

npx expo install expo-updates
eas update:configure

In app.json verrà aggiunta la sezione:

{
  "expo": {
    "runtimeVersion": {
      "policy": "appVersion"
    },
    "updates": {
      "url": "https://u.expo.dev/your-project-id",
      "channel": "production"
    }
  }
}

Per pubblicare un update:

eas update --channel production --message "Fix login retry bug"

Il bundle viene compilato, caricato sul CDN globale di Expo, e gli utenti lo scaricano in background al prossimo avvio dell'app — purché la loro runtimeVersion corrisponda.

Regola d'oro: ogni modifica che tocca app.json nativi (permessi, plugin, versioni native) richiede un incremento di runtimeVersion e quindi una nuova build. EAS lo verifica con il fingerprint del progetto, quindi non puoi davvero sbagliarti — ma sapere il "perché" aiuta quando un OTA non parte.

EAS Workflows: CI/CD nativo

EAS Workflows, lanciato in beta nel 2024 e maturato nel 2026, è l'alternativa Expo-native a GitHub Actions per scenari mobile. Crea un file .eas/workflows/build-and-submit.yml:

name: Build and Submit on main
on:
  push:
    branches: [main]

jobs:
  build_android:
    type: build
    params:
      platform: android
      profile: production
  build_ios:
    type: build
    params:
      platform: ios
      profile: production
  submit_android:
    needs: [build_android]
    type: submit
    params:
      platform: android
  submit_ios:
    needs: [build_ios]
    type: submit
    params:
      platform: ios

Avvia il workflow con:

eas workflow:run build-and-submit.yml

Oppure lascialo eseguire automaticamente al merge su main. Il vantaggio chiave? I workflow EAS sono fingerprint-aware. Se nessun file nativo è cambiato, skippano automaticamente la build e pubblicano un OTA update — risparmiando build credit e tempo. È una di quelle ottimizzazioni che, una volta provate, non torni indietro.

Integrazione con GitHub Actions

Se invece preferisci GitHub Actions (e sono in tanti, per coerenza col resto della pipeline), il workflow tipico è:

name: EAS Production Build
on:
  push:
    branches: [main]
    tags: ['v*']

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - uses: expo/expo-github-action@v8
        with:
          eas-version: latest
          token: ${{ secrets.EXPO_TOKEN }}
      - run: npm ci
      - run: eas build --platform all --profile production --non-interactive --auto-submit

Genera il token con eas whoami --token e salvalo come secret EXPO_TOKEN nel repo.

Ottimizzare tempi e costi delle build

Una build iOS production può durare 15-25 minuti su m-medium, 8-12 minuti su m-large. Le build Android tipicamente 5-10 minuti. Qualche idea per ottimizzare:

Usa OTA invece di rebuild: per fix JavaScript, eas update costa zero build credit e raggiunge gli utenti in minuti.
Cache delle dipendenze: EAS cacha automaticamente node_modules e CocoaPods se il package-lock.json non è cambiato. Mantieni il lockfile sotto controllo versione.
Fingerprint-aware builds: tramite EAS Workflows, salti le build quando solo il JS è cambiato.
Resource class: m-large costa più credit ma dimezza i tempi; spesso conviene su progetti grandi.
Local builds per debug: eas build --local esegue la build sulla tua macchina senza consumare credit, utile quando devi capire perché un certo errore appare solo in ambiente cloud.

Problemi comuni e troubleshooting

"Invalid provisioning profile"

Causa più frequente: cambio di Bundle Identifier in app.json senza rigenerare i credentials. Soluzione:

eas credentials
# iOS production Provisioning Profile Remove
# poi rilancia la build, EAS rigenera automaticamente

"Version code has already been used" (Android)

Hai disabilitato autoIncrement e il versionCode è in conflitto. Soluzione:

// in eas.json
"production": {
  "autoIncrement": true,
  "android": { "buildType": "app-bundle" }
}

"App Tracking Transparency permission missing"

Dal 2025 Apple richiede dichiarazioni esplicite anche per SDK come Firebase Analytics. Aggiungi al plugin di app.json:

{
  "expo": {
    "ios": {
      "infoPlist": {
        "NSUserTrackingUsageDescription": "Usiamo questo dato per migliorare l'esperienza personalizzata."
      }
    },
    "plugins": [
      ["expo-tracking-transparency", {
        "userTrackingPermission": "Usiamo questo dato per migliorare l'esperienza personalizzata."
      }]
    ]
  }
}

"EAS Update non raggiunge gli utenti"

Tre cause tipiche:

Runtime version mismatch: la build installata ha runtimeVersion diversa da quella dell'update. Verifica con eas update:list.
Channel sbagliato: hai pubblicato su preview ma la build production è su production (capita più spesso di quanto si pensi, di solito di venerdì pomeriggio).
Update check policy: il default è ON_LOAD; verifica che non sia stato cambiato in ON_ERROR_RECOVERY.

Best practice per il 2026

Versionamento remoto: "appVersionSource": "remote" elimina merge conflict su buildNumber.
Branch protection: le build production partono solo da main, mai da feature branch.
Secrets centralizzati: usa eas env:create per le variabili sensibili invece di committarle.
Audit dei plugin nativi: ogni plugin aggiunge superficie d'attacco e tempi di build. Rivedili semestralmente.
Strategia OTA + Build: regola pratica — il 90% dei deploy dovrebbe essere OTA, il 10% build native.
Test pre-submission: usa eas build:run per scaricare l'ultimo IPA/APK e testarlo localmente prima della submission.
Rollback plan: eas update:republish consente di tornare a un update precedente in pochi secondi se qualcosa va storto. E qualcosa, prima o poi, va storto.

FAQ

Posso usare EAS Build con un progetto React Native bare (senza Expo)?

Sì. EAS Build supporta sia progetti Expo managed che bare workflow. È sufficiente eseguire eas build:configure nella root di qualsiasi progetto React Native creato con npx react-native o create-react-native-app. EAS rileva automaticamente la struttura e configura un eas.json compatibile.

Qual è la differenza tra EAS Update e CodePush?

Microsoft ha annunciato la fine del supporto a CodePush nel marzo 2025; EAS Update è ormai lo standard de facto per OTA su React Native. EAS Update offre integrazione nativa con expo-updates, gestione automatica di runtime version e fingerprint, CDN globale e dashboard centralizzato. Inoltre supporta canali multipli, rollback istantaneo e funziona anche su progetti bare workflow.

Quanto costa pubblicare un'app con EAS nel 2026?

Per un team singolo che pubblica una piccola app, il piano Free di EAS (15 build Android + 15 iOS al mese) è sufficiente. A questo si aggiungono i costi obbligatori degli store: $99/anno per Apple Developer Program e $25 una tantum per Google Play. Per team che fanno deploy frequenti, lo Starter a $19/mese ($45 di build credit inclusi) è il sweet spot. La Production a $199/mese si giustifica solo con app a forte traffico (oltre 5.000 MAU su OTA).

Posso evitare l'upload manuale del primo AAB su Play Store?

No, è un limite della Google Play Developer API, non di EAS. Il primo AAB di una nuova app deve essere caricato manualmente almeno una volta dalla Play Console. Dopo questa prima volta, tutti gli upload successivi possono essere automatizzati via EAS Submit. Su App Store, invece, l'upload è completamente automatizzabile fin dalla prima submission.

Come gestisco app native con codice modificato manualmente nella cartella ios/ o android/?

EAS Build supporta i cosiddetti "prebuild ejected" o bare workflow. Le modifiche manuali nelle cartelle ios/ e android/ vengono incluse nella build. Tuttavia, per progetti che vogliono restare allineati alle best practice Expo, è consigliato usare config plugin che modificano programmaticamente la configurazione nativa al momento del prebuild — così le modifiche restano in versione e sopravvivono a npx expo prebuild --clean.

Conclusioni

Nel 2026 EAS Build & Submit non sono più "uno dei modi" per deployare React Native — sono lo standard. La pipeline che abbiamo descritto, ben configurata in eas.json con build profile separati per development, preview e production, gestione automatica dei credentials, CI/CD via EAS Workflows e una strategia OTA aggressiva via EAS Update, riduce il tempo dal commit alla produzione da giorni a minuti.

L'investimento iniziale di una giornata per impostare correttamente la pipeline si ripaga nelle prime due release: meno errori di submission, zero gestione manuale di certificati, build riproducibili e team allineato. Combinato con gli altri tasselli — Expo Router v6 per la navigazione, Reanimated 4 per le animazioni, FlashList v2 per le liste e una solida strategia di state management — hai una stack React Native production-ready completa per il 2026. Ora tocca a te: apri il terminale, lancia eas init e ci vediamo dall'altra parte della pipeline.