EAS Update React Native-ban: OTA frissítések teljes útmutatója (2026)

Frissítve: 2026. július 14.

Az EAS Update az Expo által üzemeltetett Over-the-Air (OTA) frissítési szolgáltatás, ami lehetővé teszi, hogy egy React Native alkalmazás JavaScript bundle-jét és statikus asset-jeit másodpercek alatt frissítsd a felhasználók készülékein anélkül, hogy új build-et küldenél az App Store-ba vagy a Play Store-ba. 2026-ra az EAS Update jórészt átvette a Microsoft CodePush helyét a legtöbb Expo és bare React Native projektben, és teljes integrációt kínál csatornákkal, runtime verziókkal, staged rollout-tal és kriptográfiai kódaláírással.

• Az EAS Update csak JavaScript és asset változásokat tud átvinni; natív modul módosításához továbbra is új store build kell.
• A runtimeVersion mező pontosan meghatározza, hogy egy natív build melyik update-eket fogadhatja el. Helytelen beállítás fehér képernyőt okozhat (ezt sajnos élesben tanultam meg).
• A csatornák (channels) build-időben kötődnek egy branch-hez, így ugyanaz a build futás közben más frissítést kaphat production és preview módban.
• A staged rollout 2025 óta stabil funkció; százalékos alapon terheli a felhasználókat, és bármikor visszavonható az eas update:republish paranccsal.
• A kódaláírás (code signing) man-in-the-middle és insider támadások ellen véd, és 2026-ban ajánlott minden pénzügyi vagy egészségügyi alkalmazásnak.
• Az EAS Update ingyenes csomagja havi 1000 MAU-ig terjed, ezen felül a Production terv MAU-alapú átalánydíjjal skálázódik.

Mi az EAS Update és mikor érdemes használni?

Az EAS Update az Expo Application Services (EAS) egyik szolgáltatása. Lehetővé teszi, hogy a JavaScript kódot, a React komponenseket, a stílusokat, a képeket és a többi statikus asset-et közvetlenül a felhasználók készülékére küldd új natív build kiadása nélkül. Amikor a felhasználó megnyitja az alkalmazást, az expo-updates könyvtár lekérdezi az Expo szerverét, letölti az új bundle-t a háttérben, és a következő indításkor betölti azt. A folyamat teljes egészében az Apple App Store és a Google Play Store irányelvei szerint működik, mert csak értelmezett kódot változtat, nem natív binárist.

Őszintén szólva ez az egyik olyan eszköz, amiért egy komolyabb React Native projektben mindenki azonnal hálás lesz. Néhány tipikus eset, amikor bevetem: kritikus hibajavítások gyors kiszállítása (pl. crash-fix egy backend endpoint változás miatt), UI szövegek és feliratozás módosítása, A/B teszthez különböző JavaScript variánsok kiterítése különböző csatornákra, valamint sürgős biztonsági javítások, ahol nincs idő 24–72 órás store review-ra várni.

Ne használd viszont OTA-t natív függőség verzió emeléshez, új natív modul hozzáadásához, Info.plist vagy AndroidManifest.xml változtatáshoz. Ezek mindig új store build-et igényelnek. A hivatalos Expo EAS Update dokumentáció részletesen ismerteti a támogatott és nem támogatott változtatásokat.

EAS Update vs. CodePush 2026-ban: mi változott?

2024 áprilisában a Microsoft bejelentette a Visual Studio App Center (és vele együtt a CodePush) kivezetését, ami 2025 márciusától kizárólag self-hosted vagy külső szolgáltatóra épülő átállásra kényszerítette a projekteket. Ekkortól kezdve az EAS Update és néhány open-source alternatíva (Shipy, expo-updates + custom server) vette át a piacot. A gyakorlatban az EAS Update ma is a legszélesebb körben használt megoldás bare React Native és Expo projektekhez egyaránt, és 2026-ban már monolitikus CDN-kiszolgálást, per-branch analytics-et és fine-grained rollout-vezérlést kínál.

Az alábbi táblázat összefoglalja a két megoldás közötti különbségeket a 2026-os állapot szerint:

Jellemző	EAS Update	CodePush (App Center)
Állapot 2026-ban	Aktív, hivatalosan támogatott	2025.03.31-én kivezetve
Bare React Native támogatás	Igen, expo-updates modullal	N/A
Csatorna & branch-modell	Build-time channel + futásidőben branch	Deployment key alapú
Staged rollout	1–100% százalékos, granularis	Egész számos %
Kódaláírás	Beépített RSA-alapú signing	Nincs beépített
Analytika	Manifest-lekérdezés + install metrikák	Nincs
Ingyenes szint	1000 MAU/hó	Megszűnt

Az EAS Update beállítása lépésről lépésre

Új projektnél a legegyszerűbb út a npx create-expo-app template használata, ami 2026-ban alapértelmezésben tartalmazza az expo-updates modult. Meglévő projekthez viszont manuális bekötés kell. Az alábbi lépések Expo SDK 55-öt és eas-cli 20.x verziót feltételeznek. Ha még nem használsz Expo új architektúrát, érdemes előbb végigolvasnod az Expo SDK 55 és Új Architektúra útmutatót.

1. lépés: EAS CLI telepítése és bejelentkezés

npm install --global eas-cli@latest
eas login
eas whoami

2. lépés: A projekt inicializálása

cd my-app
eas init
eas update:configure

Ez a parancs generálja az app.config.ts-ben az updates.url és runtimeVersion mezőket, és a eas.json-hoz hozzáadja a channel hivatkozásokat build profilonként.

3. lépés: Az app.config.ts ellenőrzése

// app.config.ts
import { ExpoConfig } from 'expo/config';

const config: ExpoConfig = {
  name: 'MyApp',
  slug: 'my-app',
  version: '1.0.0',
  runtimeVersion: { policy: 'appVersion' },
  updates: {
    url: 'https://u.expo.dev/<PROJECT_ID>',
    fallbackToCacheTimeout: 0,
    checkAutomatically: 'ON_LOAD',
  },
  extra: {
    eas: { projectId: '<PROJECT_ID>' },
  },
};

export default config;

4. lépés: Az első update publikálása

# development branch-re
eas update --branch development --message "Első teszt update"

# production branch-re
eas update --branch production --message "v1.0.1 hotfix"

Csatornák és branch-ek: hogyan működik a szétosztás?

A csatorna (channel) és a branch az EAS Update két alapfogalma, és gyakran összekeverik őket. A channel egy build-time konstans, amit a natív binárisba égetsz be az eas build során: például production, preview, staging. Ezt a felhasználó nem tudja utólag módosítani, mert a natív kódba került. A branch ezzel szemben futásidőben mutatható át: bármikor átirányíthatod a production csatornát egy másik branch-re az eas channel:edit paranccsal, és a következő manifest lekérdezéskor a felhasználók már az új branch-en lévő update-et fogják letölteni.

Ez a szétválasztás teszi lehetővé a hotfix-eket rollback nélkül is. Ha a production csatornán problémát találsz, létrehozhatsz egy production-rollback branch-et a régi verzióval, és átirányíthatod a csatornát oda. Ehhez hasonló csatorna-orientált navigációt láthatsz az Expo Router v4 fájl-alapú navigáció útmutatóban, ahol a routing-manifest hasonló elveken kap runtime frissítést.

# új branch létrehozása és publikálás
eas update --branch hotfix-2026-07 --message "Login crash javítás"

# a production csatorna átirányítása
eas channel:edit production --branch hotfix-2026-07

# ellenőrzés
eas channel:view production

Csatorna beállítása a build-profilban

// eas.json
{
  "build": {
    "production": {
      "channel": "production",
      "distribution": "store"
    },
    "preview": {
      "channel": "preview",
      "distribution": "internal"
    }
  }
}

Runtime version: mikor kell új natív build?

A runtimeVersion mező a legkritikusabb konfigurációs érték az egész EAS Update rendszerben. Ez egy szigorú kompatibilitási jelző, ami megmondja az expo-updates modulnak, hogy egy adott natív build melyik JS bundle-öket fogadhatja el. Ha a bundle és a natív binaris runtime verziója nem egyezik pontosan, a manifest lekérdezéskor a szerver „nincs elérhető update” választ ad, és a felhasználó a beépített bundle-t futtatja tovább. Ez így van akkor is, ha valójában frissebb bundle érhető el (én magam is beleszaladtam már ebbe a csapdába, elég frusztráló, amíg rájön az ember).

Három policy közül választhatsz: appVersion (a version mezőt használja), nativeVersion (natív build-time verzió), vagy egy fix string. 2026-ban a javasolt a fingerprint policy, ami az Expo 51 óta stabil, és automatikusan hash-eli a natív dependenciákat, így pontosabb, mint a manuális verziózás. A runtime-version dokumentáció részletesen bemutatja a különbségeket.

// Ajánlott 2026-ban: fingerprint policy
{
  "expo": {
    "runtimeVersion": { "policy": "fingerprint" },
    "updates": {
      "url": "https://u.expo.dev/<PROJECT_ID>"
    }
  }
}

Fokozatos kiadás (staged rollout)

A staged rollout (más néven progressive rollout vagy phased release) lehetővé teszi, hogy egy új update csak a felhasználók előre megadott százalékának legyen elérhető, mielőtt teljes körben kiterítenéd. Ez 2025 óta hivatalosan is stabil funkció az EAS-ben, és nagy termelési appoknál kritikus a kockázatcsökkentéshez. Egy tipikus rollout-menetrend: 1% → 5% → 25% → 100%, minden lépcső között 30–120 perces monitorozási ablakkal, ahol a Sentry crash rate, a backend hibaráta és a felhasználói metrikák stabilitását nézed.

# Új update publikálása 5%-os rollout-tal
eas update --branch production   --message "v1.2.0 új keresés"   --rollout-percentage 5

# Felskálázás 25%-ra
eas update:edit --rollout-percentage 25

# Teljes kiterítés
eas update:edit --rollout-percentage 100

Fontos, hogy a százalékosítás determinisztikus és felhasználó-alapú. Minden készülék egy stabil hash-t kap az installationId alapján, így ugyanaz a felhasználó vagy megkapja a rollout-ot, vagy nem, de nem fog véletlenszerűen ugrálni közte és a régi verzió között. Ez különösen fontos az A/B teszteknél, ahol az élményfolytonosság alapkövetelmény. A modern kliensoldali állapotkezelést és cache-t érdemes ehhez a Zustand és TanStack Query gyakorlati útmutató szerint kialakítani, mert a rollout kihatással lehet a szerver-válaszok cache invalidálására is.

Rollback: hogyan vonjuk vissza a hibás frissítést?

Ha egy publikált update problémát okoz, két rollback-mechanizmus áll rendelkezésre. Az első és leggyorsabb az update republish: az eas update:republish paranccsal az adott branch előző update-jét jelölöd ki aktívnak. Ez másodpercek alatt visszahozza a stabil állapotot, mert nem kell új bundle-t buildelni és feltölteni; pusztán a manifest-mutatót változtatod meg.

# A branch előző update-jeinek listázása
eas update:list --branch production --limit 10

# Rollback egy konkrét update-re
eas update:republish --branch production   --group <UPDATE_GROUP_ID>   --message "Rollback v1.2.0 crash miatt"

A második lehetőség a channel átirányítás: ha a hibás release egy dedikált branch-en van, egyszerűen visszamutathatod a production csatornát egy régebbi, ismert-jó branch-re az eas channel:edit paranccsal. Ez a módszer különösen hasznos, ha a rollback állandósul (pl. 24–48 órán át élsz az előző verzióval, amíg egy komplexebb natív fix érkezik store review-n).

Kódaláírás (code signing) beállítása

Alapértelmezés szerint az update-eket HTTPS-en keresztül tölti le az app, de nincs kriptográfiai bizonyíték arra, hogy az update-et te tetted közzé. Egy sikeres man-in-the-middle vagy DNS-hijack támadás elméletileg rosszindulatú JS kódot juttathat el a felhasználóidhoz. A code signing ezt oldja meg: minden update-et a te privát kulcsoddal írsz alá, és a beépített natív binaris a nyilvános kulccsal verifikálja a manifestet, mielőtt bármit végrehajtana.

A beállításhoz először generálj egy RSA kulcspárt az eas-cli-vel, majd add hozzá a nyilvános kulcsot az app.config.ts-hez, végül minden eas update hívásnál használd a --private-key-path flag-et. A code signing hivatalos leírása a teljes protokollt bemutatja.

# Kulcspár generálás
npx expo-updates codesigning:generate   --key-output-directory keys   --certificate-output-directory certs   --certificate-validity-duration-years 10   --certificate-common-name "MyApp"

# Konfiguráció beolvasása
npx expo-updates codesigning:configure   --certificate-input-directory certs   --key-input-directory keys

# Aláírt update publikálás
eas update --branch production   --message "Aláírt hotfix"   --private-key-path=keys/private-key.pem

EAS Update költségek 2026-ban

Az EAS Update négy csomagszinten érhető el 2026 közepén. A Free csomag havi 1000 MAU-ig (Monthly Active User) ingyenes, korlátlan branch-el és 500MB asset-tárolással, ami tökéletes indie fejlesztők és kisebb projektek számára. A Production csomag ($19/hó) 20 000 MAU-t tartalmaz, ezután MAU-alapú átalánydíjjal skálázódik ($0.005/MAU 20k felett). Az Enterprise szintre lépéskor ($2500+/hó) SLA-val, dedikált supporttal és private CDN régió választással jár. Az árazás pontos részletei a hivatalos Expo pricing oldalon érhetőek el, és rendszeresen módosulnak, ezért érdemes évente ellenőrizni.

Egy apróság, amit érdemes fejben tartani: MAU-nak azt tekinti az Expo, aki legalább egyszer lekérdezte a manifest endpoint-ot az adott hónapban. Tehát nem csak azt, aki ténylegesen le is töltött egy új update-et. Ez azt jelenti, hogy egy nagy telepített bázis, ahol a felhasználók csak megnyitják az appot, ugyanúgy MAU-t generál, mint egy aktív rollout. Nagy alkalmazásoknál (100k MAU felett) ez jelentősen befolyásolhatja a döntést, hogy self-hosted expo-updates szervert érdemesebb-e üzemeltetni.

Gyakran ismételt kérdések

Miben különbözik az EAS Update és a hagyományos app store frissítés?

Az EAS Update kizárólag a JavaScript bundle-t és a statikus asset-eket cseréli, tehát nem érint natív kódot. Az app store frissítéssel szemben nincs review folyamat, és másodpercek alatt eljut a felhasználókhoz, viszont natív modul vagy engedélyváltozás esetén kötelező marad a store újrapublikálás.

Lehet-e OTA frissítéssel új natív függőséget hozzáadni?

Nem. Ha új natív modult (pl. react-native-firebase) telepítesz, vagy egy meglévő modul natív kódját frissíted, új eas build szükséges. Ilyenkor a runtimeVersion-t is módosítani kell, hogy a régi build-ek ne kapják meg a rájuk inkompatibilis JS bundle-t.

Mennyibe kerül az EAS Update kis projekteknek?

Az EAS Update Free csomag havi 1000 aktív felhasználóig teljesen ingyenes, korlátlan branch-el. Ez a legtöbb indie és korai szakaszban lévő projekthez elegendő, és később fizetős csomagra frissíthetsz downtime nélkül.

Hogyan tudom visszavonni (rollback) a hibás EAS Update-et?

Használd az eas update:republish parancsot az adott branch előző update-jével, vagy irányítsd át a csatornát egy régebbi branch-re az eas channel:edit paranccsal. Mindkét módszer másodperceken belül él, és nem igényel új natív build-et.

Sértik-e az OTA frissítések az App Store irányelveit?

Nem, amíg csak JavaScript és asset változásokat viszel át, és nem módosítod az app fő funkcionalitását olyan módon, ami megkerülné a store review-t. Az Apple App Store Review Guidelines 3.3.2 kifejezetten engedélyezi az OTA frissítéseket interpretált kódhoz, feltéve, hogy az általános felhasználói élmény konzisztens marad.

Milyen gyakran kell új natív build-et készíteni EAS Update mellett?

Attól függ, milyen mértékben változnak a natív függőségeid. Egy stabil projektben, ahol a natív modulokat ritkán frissíted, akár 3–6 hónapig is elmehetsz új store build nélkül. Új Expo SDK vagy jelentős React Native verzió esetén viszont mindenképp új build kell.