Expo EAS 2026: React Native -julkaisuo…

Q: Miten peruutan väärän EAS Update -julkaisun?

Aja eas update:rollback --branch production . Tämä republisoi edellisen tunnetusti hyvän julkaisun tuoreena bundlina, jonka jälkeen kaikki laitteet saavat oikean version seuraavan käynnistyksen yhteydessä. Pelkkä rollout-prosentin laskeminen ei riitä, koska aiemmin ladattu bundle säilyy laitteessa.

Päivitetty: 19. heinäkuuta 2026

Expo Application Services (EAS) on Expo-tiimin pilvipohjainen julkaisualusta React Native -sovelluksille. Se rakentaa iOS- ja Android-bundlit pilvessä ilman Xcodea tai Android Studiota, hoitaa allekirjoitusavaimet ja lähettää valmiin sovelluksen App Storeen sekä Google Playhin yhdellä komennolla. Vuonna 2026, kun Expo SDK on versiossa 55 ja React Nativen uusi arkkitehtuuri on oletus, EAS Build, EAS Submit ja EAS Update muodostavat yhtenäisen putken kehityksestä kauppajulkaisuun ja OTA-päivityksiin asti. Julkaisin oman rahaliikennesovellukseni juuri tätä putkea käyttäen, ja käyn tässä oppaassa koko työnkulun läpi konkreettisilla esimerkeillä.

EAS Build ajaa iOS- ja Android-bundlien käännökset pilvessä. Macia ei tarvita iOS-julkaisuun, koska Expon macOS-runnerit hoitavat Xcode-käännöksen.
eas.json määrittää build-profiilit (development, preview, production), sisältää submit-asetukset ja tukee extends-perintää DRY-konfiguraatioon.
EAS Submit lähettää bundlet App Store Connectiin ja Google Play Consoleen yhdellä komennolla, kunhan Apple Developer -tili ($99/v) ja Google Play -kehittäjätili ($25 kertamaksu) ovat olemassa.
EAS Update jakaa JavaScript- ja asset-muutokset OTA:na. Kanavat pidetään binäärissä, ja haarat päivittyvät julkaisujen välillä.
Suositeltu rollout-kadenssi on 1 % tunnin ajan, sitten 10 % 4–8 tuntia, sitten 100 %; noin 70–80 % kaatumisia paljastuu ensimmäisen tunnin aikana.
EAS Workflows kirjoittaa .eas/workflows/deploy.yml-tiedoston ja päättää fingerprintin perusteella, tarvitaanko uusi natiivibinääri vai riittääkö OTA-päivitys.

Mikä on EAS ja miksi käyttää sitä 2026

Expo Application Services on Expon ylläpitämä palvelukokonaisuus, joka koostuu neljästä osasta: EAS Build (natiivikäännökset pilvessä), EAS Submit (kauppapalautus), EAS Update (OTA-jakelu) ja EAS Workflows (CI/CD-orkestrointi). Palvelut on suunniteltu Expo- ja pelkkiä React Native -projekteja varten. Voit ottaa ne käyttöön myös projektissa, joka ei käytä Expo SDK:ta, kunhan lisäät expo-modules-core- ja expo-updates-riippuvuudet.

Vuoteen 2026 mennessä sekä Apple että Google ovat kiristäneet vaatimuksia allekirjoitusten, tietosuojamanifestien ja SDK-ilmoitusten osalta. EAS Buildin oletuskonfiguraatiot pitävät nämä ajan tasalla, etkä joudu jahtaamaan ITMS-90683-virhettä Xcoden lokista, koska Expon runnerit päivittävät tarvittavat kentät automaattisesti. Android-käännökset ajetaan Linux-runnereilla Google Cloud Platformissa ja iOS-käännökset Expon macOS-pilvessä, joten voit julkaista iOS-sovelluksen kokonaan Windows- tai Linux-työpöydältä.

EAS:n vahvin myyntivaltti on integraatio. Sama eas.json-tiedosto ohjaa buildia, submitia ja updatea, ja kanavat sitovat binääriversion OTA-virtaan. Kun tähän lisätään EAS Workflowsin fingerprint-pohjainen päätöslogiikka, saat julkaisuputken, joka rakentaa uuden natiivibinäärin vain kun natiivikoodi muuttuu, ja lähettää muut muutokset OTA:na sekunneissa.

Ympäristön valmistelu ja projektin liittäminen

Aloita asentamalla eas-cli globaalisti ja kirjautumalla Expo-tilillesi. Suositeltu Node-versio 2026 on Node 22 LTS, mutta EAS-runnerit tukevat myös Node 20:tä. Työkalut olettavat, että projektisi käyttää Expo SDK 52 tai uudempaa; vanhemmilla SDK-versioilla eas-json-skeema poikkeaa.

# Asenna EAS CLI globaalisti
npm install -g eas-cli@latest

# Kirjaudu Expo-tilille (avaa selain OAuth-vuolle)
eas login

# Liitä paikallinen projekti Expo-organisaatioon
cd polku/react-native-projektiin
eas init

# Luo oletusarvoinen eas.json ja kytke build-profiilit
eas build:configure

eas init luo tai päivittää app.json:iin extra.eas.projectId-kentän, joka linkittää paikallisen projektin Expon dashboardiin. Jos aiot käyttää EAS Updatea, komento asettaa myös updates.url-kentän muotoon https://u.expo.dev/<projectId>.

Ennen kuin ajat ensimmäisen buildisi, on syytä käydä läpi natiivikonfiguraatio. Tarkasta erityisesti:

Bundle identifier ja package name. Nämä on lukittava ennen ensimmäistä store-julkaisua, koska niitä ei voi muuttaa jälkikäteen.
Versionumerointi. Käytä "appVersionSource": "remote" eas.json:issa, jolloin EAS hallinnoi buildNumber- ja versionCode-arvot puolestasi.
Ympäristömuuttujat. Vie EXPO_PUBLIC_-etuliitteiset muuttujat EAS Dashboardin kautta. Älä koskaan tallenna avaimia repositorioon.

Jos siirryt vanhemmasta projektista, lue myös meidän Expo SDK 53–55 ja uuden arkkitehtuurin opas, joka käsittelee uuden arkkitehtuurin päälle laittamisen ja Hermes-vaatimukset. Nämä vaikuttavat siihen, miten EAS Build kääntää sovelluksesi.

Näin määrität eas.json-tiedoston

eas.json on projektin juuressa oleva JSON-tiedosto, joka määrittelee build-profiilit, submit-asetukset ja EAS CLI:n vaatiman version. Sen ymmärtäminen on tärkein yksittäinen taito EAS-julkaisujen hallinnassa. Yksinkertaisimmillaan tiedosto näyttää tältä:

{
  "cli": {
    "version": ">= 16.18.0",
    "appVersionSource": "remote"
  },
  "build": {
    "development": {
      "developmentClient": true,
      "distribution": "internal",
      "channel": "development",
      "ios": { "simulator": true }
    },
    "preview": {
      "distribution": "internal",
      "channel": "preview",
      "android": { "buildType": "apk" }
    },
    "production": {
      "autoIncrement": true,
      "channel": "production"
    }
  },
  "submit": {
    "production": {
      "ios": {
        "appleId": "[email protected]",
        "ascAppId": "1234567890",
        "appleTeamId": "ABCDE12345"
      },
      "android": {
        "serviceAccountKeyPath": "./google-play-service-account.json",
        "track": "production"
      }
    }
  }
}

Kolme profiilia (development, preview ja production) riittävät useimmille tiimeille. Development-profiili sisältää expo-dev-client-tuen, jolloin voit ladata JS-bundlin Metro-palvelimelta ja saat React DevTools -yhteyden. Preview tuottaa jaettavia APK- tai ad hoc IPA -tiedostoja, joita voit jakaa testiryhmälle URL-linkillä. Production tuottaa allekirjoitetut store-versiot, jotka menevät EAS Submitin läpi kauppaan.

Kun profiilit alkavat monistua, hyödynnä extends-avainta pitääksesi konfiguraation DRY:nä:

{
  "build": {
    "base": {
      "node": "22.11.0",
      "env": { "EXPO_PUBLIC_API_URL": "https://api.example.com" }
    },
    "production": {
      "extends": "base",
      "channel": "production",
      "autoIncrement": true
    },
    "staging": {
      "extends": "base",
      "channel": "staging",
      "distribution": "internal",
      "env": { "EXPO_PUBLIC_API_URL": "https://staging-api.example.com" }
    }
  }
}

Perintää voi ketjuttaa jopa viiden tason syvyyteen. Tarkka skeema löytyy virallisesta eas.json-viitedokumentaatiosta. Muista sitoa jokainen build-profiili haluttuun channel-nimeen jo tässä vaiheessa. Tämä on ainoa hetki, jolloin kanava kirjoittuu binääriin.

EAS Build käytännössä: development, preview ja production

EAS Buildin peruskomento on suoraviivainen: valitse alusta ja profiili, ja työ jonottuu Expon dashboardiin. Ensimmäinen ajo pyytää valitsemaan tunnistetiedot. Anna EAS:n hallita niitä automaattisesti, ellei sinulla ole erityistä syytä olla tekemättä niin (esim. yrityksen keskitetty avainhallinta).

# Ensimmäinen development-build sisäistä testausta varten
eas build --platform ios --profile development
eas build --platform android --profile development

# Preview-build QA:lle: molemmat alustat rinnakkain
eas build --platform all --profile preview

# Tuotanto-build ilman automaattista submitia
eas build --platform all --profile production

# Tuotanto-build ja submit yhdellä komennolla
eas build --platform all --profile production --auto-submit

Build-jono näkyy https://expo.dev-dashboardissa. Ilmainen suunnitelma antaa muutaman buildin kuukaudessa, kun taas maksulliset suunnitelmat lisäävät rinnakkaisia buildeja, isompaa resurssiluokkaa (large M1/M2 -runnereille) ja nopeamman jonon. Omassa käytössäni iOS-buildi kestää keskimäärin 8–15 minuuttia ja Android 5–10 minuuttia.

Resurssiluokka määritellään profiilissa avaimella resourceClass. Isot monorepot ja natiivikoodia paljon käyttävät projektit hyötyvät large-luokasta:

{
  "build": {
    "production": {
      "resourceClass": "large",
      "ios": { "resourceClass": "large" }
    }
  }
}

Kun buildi valmistuu, saat linkin allekirjoitettuun IPA- tai AAB-tiedostoon. Ennen kauppaan lähettämistä kannattaa tehdä savutestit oikealla laitteella. Asenna preview-buildi TestFlightin tai internal distribution -linkin kautta ja aja perustoiminnot läpi. Suoritusongelmiin ja bundlin turvotukseen kannattaa palata React Nativen suorituskyvyn optimointioppaassamme mainituilla mittareilla.

EAS Submit: App Storeen ja Google Playhin ilman käsityötä

EAS Submit lataa valmiin buildin App Store Connectiin tai Google Play Consoleen. Se on itsenäinen palvelu, mutta useimmiten ajat sen samasta profiilista --auto-submit-lipulla. Jotta submit onnistuu, sinulla on oltava:

Apple Developer -tili (99 $/vuosi) ja App Store Connect App ID (ascAppId). Voit generoida App-Specific-salasanan tai käyttää App Store Connect API -avainta. Jälkimmäinen on suositeltavampi CI:ssä.
Google Play -kehittäjätili (25 $ kertamaksu) ja Service Account -avain JSON-muodossa. Avainta hallitaan Google Cloud Consolessa, ja sille annetaan Release Manager- tai Service Account User -rooli Play Consolessa.

# Manuaalinen submit valmiista buildista (kysyy build-ID:n)
eas submit --platform ios --profile production
eas submit --platform android --profile production

# Sido buildi ja submit yhteen komentoon
eas build --platform all --profile production --auto-submit-with-profile production

Rehellisesti sanottuna kannattaa määrittää submit-profiili jokaista päätetilaa varten. Alla esimerkki, jossa production menee internal-testaukseen Play Consolessa ja alpha TestFlightiin:

{
  "submit": {
    "production": {
      "ios": {
        "appleId": "[email protected]",
        "ascAppId": "1234567890",
        "appleTeamId": "ABCDE12345"
      },
      "android": {
        "serviceAccountKeyPath": "./credentials/google-service-account.json",
        "track": "internal",
        "releaseStatus": "draft"
      }
    }
  }
}

releaseStatus: "draft" Google Playn puolella ja iOS:n whatsNew-kenttä ovat pieniä yksityiskohtia, jotka helposti unohtuvat. Nämä on hyvä pitää versionhallinnan ulkopuolella EAS Secrets-arvoina. Muista, että App Storen review-jono kestää keskimäärin 24–48 tuntia, kun taas Google Play Console voi julkaista internal testing -kanavan alle tunnissa. Yksityiskohdat kummankin kaupan vaatimuksista löytyvät EAS Buildin virallisesta dokumentaatiosta.

EAS Update: OTA-päivitykset, kanavat ja rolloutit

EAS Update korvaa sovelluksen JavaScript-bundlin ja staattiset assetit ilman, että käyttäjän tarvitsee ladata uutta binääriä kaupasta. Kun ajat eas update, CLI paketoi JS:n Metrolla, latautuu Expon CDN:ään ja liitetään haaraan (branch). Haara puolestaan on sidottu kanavaan (channel), joka on kirjoitettu binääriin build-hetkellä.

Tämä epäsuora sidos on OTA-turvallisuuden ydin. Voit vaihtaa production-kanavan osoittamaan uuteen haaraan, kuten production-v2-14-1, ja jos jokin menee pieleen, palautat kanavan takaisin edelliseen haaraan sekunneissa. Törmäsin viime kuussa tähän ihan käytännössä: maksunäytön validaatio hajosi tuotannossa, ja sain rollbackin läpi alle viidessä minuutissa.

# Julkaise päivitys nykyiseen haaraan
eas update --branch production --message "Fix: virheenkorjaus maksunäytön validaatiossa"

# Julkaise 5 % rollout heti
eas update --branch production --rollout-percentage 5 \
  --message "Kokeellinen paranneltu FlatList-suorituskyky"

# Kasvata rollout 25 %:iin (voit myös laskea, ei kuitenkaan 0:aan)
eas update:edit --rollout-percentage 25

# Peru julkaisu ja aja rollback
eas update:rollback --branch production

Suositeltu tuotannon kadenssi on 1 % tunniksi, sitten 10 % neljäksi tunniksi, sitten 100 %. Käytännön tuotantodatan mukaan noin 70–80 % OTA:n aiheuttamista kaatumisregressioista näkyy jo ensimmäisen tunnin 1 % rolloutin aikana. Usein käynnistyskaatumisina tai puuttuvista asseteista johtuvina virheinä. Yksityiskohtainen playbook löytyy Expon virallisesta rollouts-dokumentaatiosta.

EAS Update noudattaa myös kauppojen sääntöjä. Et voi vaihtaa natiivikoodia, muuttaa sovelluksen ydintarkoitusta tai kiertää tietosuojamanifesteja. Puitteissa pysyminen on kuitenkin todella laaja alue; kirjoitusvirheet, rikkoutunut API-sopimus, feature-flagit ja maksunäytön regressiot ovat kaikki tyypillisiä OTA-korjauksia.

EAS Workflows ja CI/CD GitHub Actionsissa

No, käydään sitten CI/CD-puoli. EAS Workflows on Expon oma CI/CD-orkestrointi, joka ymmärtää projektin fingerprintin: SHA:n natiivikoodista ja natiivikonfiguraatiosta. Fingerprintin pohjalta workflow päättää, tarvitseeko se uuden binäärikäännöksen ja submitin, vai riittääkö OTA-päivitys olemassa oleviin binääreihin.

# Alusta workflows-hakemisto
eas workflow:init deploy

# Aja putki
eas workflow:run .eas/workflows/deploy.yml

Jos yrityksessäsi käytetään jo GitHub Actionsia tai GitLab CI:tä, EAS toimii vaivattomasti niiden sisällä. Alla on kokonaisesimerkki GitHub Actions -workflowsta, joka rakentaa production-buildin ja lähettää submitin, kun main-haaraan tulee tag v*:

name: Release
on:
  push:
    tags: ['v*']

jobs:
  build-and-submit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '22'
          cache: 'npm'
      - name: Asenna riippuvuudet
        run: npm ci
      - name: Asenna EAS CLI
        run: npm install -g eas-cli@latest
      - name: Rakenna ja submit tuotantoon
        env:
          EXPO_TOKEN: ${{ secrets.EXPO_TOKEN }}
        run: |
          eas build \
            --platform all \
            --profile production \
            --auto-submit \
            --non-interactive

Avainkohdat: käytä --non-interactive-lippua, jotta prompt ei jää odottamaan, ja säilytä EXPO_TOKEN repositorion Secrets-osiossa. Sama malli toimii GitLab CI:ssä, Bitrisessa ja Buildkitessä. Kun buildi valmistuu, EAS lähettää webhookin, jonka avulla voit ilmoittaa Slackiin tai laukaista jatkotestejä. Kompleksisemmissa putkissa yhdistä React Native -debuggausvälineiden opas Sentryn tai Datadogin lähdekarttojen lataamiseen, jotta tuotantokaatumiset saadaan ratkottua nopeasti.

Yleisiä virheitä ja niiden korjaaminen

Alla on lista yleisimmistä ongelmista, joita EAS Buildissa ja Submitissa nähdään 2026. Törmäsin näihin kaikkiin viime vuoden aikana ainakin kerran.

Virhe	Yleisin syy	Ratkaisu
ITMS-90683 (iOS submit)	Puuttuva tietosuojamanifesti (`PrivacyInfo.xcprivacy`)	Päivitä Expo SDK ≥ 51 ja aja `npx expo prebuild --clean`
Gradle: Duplicate class	Kaksi kirjastoa versioi Kotlin- tai AndroidX-riippuvuutta	Lisää `expo.android.compileSdkVersion=35` ja tarkista `expo doctor`
Fingerprint mismatch (OTA)	Kanavaan päivitetty bundle ei vastaa binäärin natiivikoodia	Rakenna uusi binääri; älä lähetä OTA:na natiivikoodin muutoksia
Google Play: „Not signed with upload key"	Käytetty upload keystore ei ole rekisteröity Play App Signingiin	Aja `eas credentials`, valitse Android ja lataa oikea upload keystore
EAS build timeout	Iso monorepo ilman `--build-cache`-tukea	Ota käyttöön `large` resurssiluokka ja bundle-välimuisti

Vinkki: aja aina npx expo-doctor@latest ennen tuotanto-buildia. Työkalu tunnistaa yhteensopimattomat SDK-versiot, virheelliset natiivikonfiguraatiot ja unohtuneet plugin-parametrit. Toinen suositus on eas diagnostics, joka tekee saman tarkistuksen EAS-runnerin näkökulmasta ja raportoi resurssien tilan.

Usein kysytyt kysymykset

Mitä eroa on EAS Buildin ja EAS Updaten välillä?

EAS Build tuottaa uuden natiivibinäärin (IPA tai AAB) ja käynnistää kauppapalautuksen, kun taas EAS Update jakaa vain JavaScript-bundlin ja assetit olemassa oleviin binääreihin OTA:na. Kaikki natiivikoodin muutokset (uusi kirjasto, Info.plist-avain, Gradle-riippuvuus) vaativat EAS Buildin.

Voinko julkaista iOS-sovelluksen ilman Macia?

Kyllä. EAS Build ajaa Xcode-käännöksen Expon macOS-pilvessä, ja EAS Submit lataa valmiin IPA:n App Store Connectiin. Tarvitset Apple Developer -tilin ($99/v) ja pääsyn App Store Connectiin, mutta et paikallista Macia missään vaiheessa.

Kuinka paljon EAS Build maksaa vuonna 2026?

Ilmainen suunnitelma sisältää muutaman buildin kuukaudessa ja pienen OTA-kaistanleveyden. Production-tason suunnitelmat alkavat 19 $/kk (henkilökohtainen) ja 99 $/kk (Production), ja lisäävät rinnakkaisia buildeja, isomman resurssiluokan sekä nopeamman jonon. Enterprise-taso tarjoaa priorisoidut jonot ja SLA:n.

Miten peruutan väärän EAS Update -julkaisun?

Aja eas update:rollback --branch production. Tämä republisoi edellisen tunnetusti hyvän julkaisun tuoreena bundlina, jonka jälkeen kaikki laitteet saavat oikean version seuraavan käynnistyksen yhteydessä. Pelkkä rollout-prosentin laskeminen ei riitä, koska aiemmin ladattu bundle säilyy laitteessa.

Tarvitseeko projektin käyttää Expoa, jotta EAS toimii?

Ei. EAS toimii sekä täysin bare React Native -projekteissa että Expo-managed-projekteissa. Bare-projektissa tarvitset expo-modules-core- ja expo-updates-riippuvuudet, sekä app.json:n perustiedot. EAS lukee näistä konfiguraation ja käyttää projektin omaa ios/- ja android/-hakemistoa buildissa.