EAS Update 2026: OTA aktualizácie v React Native po konci CodePush

Aktualizované: 7. septembra 2026

EAS Update je hostovaná služba spoločnosti Expo, ktorá vám umožní posielať zmeny v JavaScripte a asset súboroch priamo do zariadení používateľov bez čakania na kontrolu v App Store alebo Play Store. Je to priama náhrada za CodePush, ktorý Microsoft vypol 31. marca 2025. Ak píšete React Native aplikáciu v roku 2026 a chcete opravovať chyby v produkcii v priebehu minút namiesto dní, EAS Update je dnes de facto štandard. V tomto článku prejdeme kompletnú konfiguráciu, kanály, vetvy, postupné rollouty, rollback a čerstvé zmeny z Expo SDK 55.

Čo je EAS Update a prečo CodePush skončil

EAS Update je súčasť platformy Expo Application Services a rieši jeden konkrétny problém: keď máte v produkcii chybu, ktorá je čisto v JavaScripte, nechcete čakať 24 hodín na kontrolu v App Store a ďalších 72 hodín, kým aktualizácia doputuje k väčšine používateľov. S EAS Update publikujete opravu jedným príkazom a zariadenia si ju stiahnu pri ďalšom otvorení aplikácie. V praxi to znamená rozdiel medzi „opravím to o hodinu“ a „ospravedlnenie na Twitteri a prácou cez víkend“.

Prečo je táto téma v roku 2026 taká horúca? Pretože Microsoft oficiálne vypol App Center 31. marca 2025, čím ukončil aj hostovanú službu CodePush. Klientská SDK knižnica react-native-code-push stále existuje v npm, ale nie je čo volať, servery sú offline. Pre tímy, ktoré roky spoliehali na CodePush, sa migrácia stala povinná, nie voliteľná. Expo EAS Update sa počas tohto obdobia stalo najčastejšie odporúčanou náhradou, pretože ponúka rovnakú funkcionalitu (kanály, cielenie podľa verzie, rollbacky), zachováva ju aktívny tím ľudí a integruje sa priamo s Expo Modules API pre natívne moduly. Alternatívy typu Branch, Appsonair alebo vlastné riešenie fungujú, ale prevádzkový overhead je značný a väčšina tímov skončí pri opätovnom vytváraní toho, čo EAS Update dáva out-of-the-box.

Ako funguje EAS Update: kanály, vetvy a runtime verzie

Toto je koncept, ktorý zvládnete raz a už nikdy vám nesplynú príkazy. EAS Update pracuje s tromi navrstvenými pojmami:

• Runtime verzia: reťazec, ktorý popisuje kompatibilitu natívneho kódu vášho buildu. Ak sa runtime verzia buildu nezhoduje s runtime verziou publikovaného update-u, klient ho neinstaluje. Toto je bezpečnostná poistka proti pádom.
• Vetva (branch): pomenovaný prúd aktualizácií, veľmi podobný Git vetve. Vetva main môže obsahovať desiatky publikácií, každá s vlastným updateId.
• Kanál (channel): statická značka zapečená do binárky v čase kompilácie. Bežné hodnoty sú production, preview, staging. Kanál v čase behu ukazuje na jednu vetvu.

Mechanika je jednoduchá. Klient sa spýta „čo je aktuálne na mojom kanáli?“, EAS server nasleduje ukazovateľ z kanála na vetvu a vráti najnovšiu publikáciu, ktorá zodpovedá runtime verzii buildu. Kanál zapečený do binárky je permanentný, ale kam ukazuje, môžete kedykoľvek zmeniť príkazom eas channel:edit. Vďaka tomu je možné celú produkciu presunúť na hotfix vetvu a späť bez toho, aby si ktokoľvek sťahoval novú aplikáciu z obchodu.

Pre runtime verzie odporúčam v roku 2026 používať policy: "fingerprint". Automaticky sa vygeneruje hash všetkých natívnych zdrojov (Podfile, gradle skripty, native moduly) a runtime sa bumpne len vtedy, keď sa tieto veci naozaj zmenia. Manuálne udržiavanie runtime verzie funguje, ale je to jedna z najčastejších príčin nočných incidentov.

Rýchle nastavenie EAS Update v Expo projekte

V mojej praxi vo fintech tíme sme celé nastavenie zvládli za popoludnie. Predpokladám, že máte Expo projekt (spravovaný alebo bare workflow) s SDK 53 alebo novším. Postupujte podľa týchto krokov.

1. Nainštalujte EAS CLI a prihláste sa:

npm install -g eas-cli
eas login
eas whoami   # over, že si prihlásený

2. Pridajte expo-updates knižnicu a inicializujte EAS:

npx expo install expo-updates
eas init
eas update:configure

Tento posledný príkaz automaticky nakonfiguruje app.json, pridá runtimeVersion s policy fingerprint a vytvorí projektové ID. Otvorte si výsledný app.json a overte, že vyzerá takto:

{
  "expo": {
    "runtimeVersion": {
      "policy": "fingerprint"
    },
    "updates": {
      "url": "https://u.expo.dev/YOUR-PROJECT-ID",
      "checkAutomatically": "ON_LOAD",
      "fallbackToCacheTimeout": 3000
    }
  }
}

3. Nakonfigurujte kanály v eas.json:

{
  "build": {
    "development": {
      "developmentClient": true,
      "distribution": "internal",
      "channel": "development"
    },
    "preview": {
      "distribution": "internal",
      "channel": "preview"
    },
    "production": {
      "channel": "production",
      "autoIncrement": true
    }
  }
}

4. Skompilujte prvý build s embedded kanálom:

eas build --profile preview --platform ios
eas build --profile production --platform all

5. Publikujte prvú aktualizáciu:

eas update --branch preview --message "Prvý OTA test, zmena farby tlačidla"

Otvorte preview build na fyzickom zariadení, force-quitnite aplikáciu a otvorte ju znovu. Aktualizácia sa stiahne na pozadí a aplikuje pri druhom štarte. Ak to funguje, ste pripravení na produkciu.

Čo môžete a nemôžete posielať cez OTA

Toto je hranica, ktorá zvyčajne rozdeľuje tímy na „posielajú s pokojom“ a „posielajú s panikou“. Pravidlo je jednoduché: ak zmena existuje výlučne v JavaScripte, TypeScripte alebo v assets/ priečinku (obrázky, fonty, JSON), môže ísť cez OTA. Ak sa dotkne čohokoľvek iného, potrebujete nový build a novú kontrolu v obchode.

Cez OTA môžete poslať:

• Opravy chýb v React komponentoch a hookoch
• Zmeny obchodnej logiky, redukcie, selectory, API klienty
• Aktualizácie tém, farebných paliet, štýlov
• Nové obrázky, ikony, fonty pridané do JS bundlu
• Zmeny v knižniciach, ktoré sú čisto JavaScript (napr. lodash, date-fns, zod)
• Prepínanie feature flagov cez remote config

Cez OTA nemôžete poslať:

• Aktualizáciu React Native, Expo SDK alebo akéhokoľvek natívneho modulu
• Nový natívny modul (napr. react-native-mmkv, react-native-reanimated)
• Zmeny v Info.plist, AndroidManifest.xml, permission strings
• Zmeny v ikone aplikácie, splash screene (tie sú súčasťou natívneho balíka)
• Nové expo-* config pluginy alebo ich konfiguráciu
• Konfiguračné zmeny v android/ alebo ios/ priečinkoch

Osobné poučenie: raz sme v jednom fintech projekte zabudli, že pridanie novej permission na iOS vyžaduje nový build. Publikovali sme OTA a aplikácia spadla na 40 % zariadení pri pokuse o použitie kamery. Odvtedy máme v deployment runbooku otázku „týka sa tejto zmeny Info.plist?“ ako povinný checkpoint.

Postupné rollouty: 5 % → 25 % → 100 %

V produkcii nikdy neposielajte OTA aktualizáciu naraz všetkým používateľom. To je najistejšia cesta k obnoveniu z rollbacku o polnoci. EAS Update podporuje postupné rollouty priamo v CLI cez parameter --rollout-percentage.

# Publikuj s 0 %, nikto ju ešte nedostane, ale je pripravená
eas update --branch production \
  --message "Oprava chyby #4271 v checkout formulári" \
  --rollout-percentage 0

# Po overení analytics zvýš na 5 %
eas update:edit --rollout-percentage 5

# O hodinu, ak nič neexploduje, choď na 25 %
eas update:edit --rollout-percentage 25

# Po 24 hodinách bez incidentov spusti plný rollout
eas update:edit --rollout-percentage 100

Dôležitý detail: rollout percentage je sticky per device. Ak zariadenie raz dostalo update pri 5 %, dostane všetky nasledujúce hodnoty percenta rovnako. Nemôžete náhodne prepínať skupiny používateľov. Vďaka tomu je rollout predvídateľný, ale znamená to, že prvých 5 % používateľov musí byť skutočne reprezentatívna vzorka.

V roku 2026 väčšina tímov, ktoré poznám, wire-uje --rollout-percentage 0 priamo do CI/CD pipeline ako default. Potom má separátny manual approval krok, ktorý postupne zvyšuje percento. Toto oddeľuje „publikáciu bundle“ od „aktivácie pre používateľov“, čo je psychologicky veľký rozdiel. Nedelegujete ju juniorovi, ktorý si nie je istý.

Ako rollbackovať zlú aktualizáciu

Existujú tri spôsoby rollbacku a každý má svoje miesto. Naučte sa všetky tri, pretože o 23:47 v noci nechcete listovať dokumentáciou.

Spôsob 1: Republikovať poslednú dobrú verziu na kanál. Toto je najčastejší a najbezpečnejší postup. EAS Update je content-addressed, takže nemôžete „vymazať“ update. Musíte publikovať novšiu verziu, ktorá logikou vráti stav späť. V praxi to znamená checkout git commitu, kde bola posledná dobrá verzia, a spustiť eas update.

git checkout <posledny-dobry-commit>
eas update --branch production \
  --message "Rollback: vrátenie na commit abc1234"

Spôsob 2: Použiť oficiálny update:rollback príkaz. Tento príkaz otočí ukazovateľ vetvy na predošlú publikovanú verziu bez potreby prepublikovania:

eas update:rollback --branch production

Spôsob 3: Vrátiť sa na embedded bundle. Ak sa OTA aktualizácia ukázala ako nefunkčná pre všetky verzie a chcete používateľov vrátiť na bundle zapečený v pôvodnej binárke, použite:

eas update:roll-back-to-embedded --branch production

Toto je „núdzová brzda“, používajte ju iba vtedy, ak viete, že embedded bundle je stabilný a novšie OTA sú horšie. V nedávnom incidente pre healthtech klienta sme tento príkaz použili po tom, čo sme omylom zabudli enabnúť hermes v produkcii a aplikácia padala pri štarte v 12 % prípadov.

Bundle diffing v SDK 55: menšie a rýchlejšie updaty

Toto je najväčšia zmena v EAS Update za rok 2026. Do Expo SDK 55 stiahol klient pri každej aktualizácii kompletný JavaScript bundle. Pri väčšej aplikácii to znamenalo 3–5 MB per update. Pre používateľa v pásme s pomalým dátovým pripojením to bolo znateľné oneskorenie a spotreba mobilných dát.

Od SDK 55 klient stiahne iba diff medzi aktuálnym a novým bundlom. V mojich testoch na aplikácii s 2,8 MB bundle dostávame diffy typicky 200–600 KB, čo je zníženie o 78–92 %. Používatelia vidia menšiu spotrebu dát, aktualizácia sa aplikuje rýchlejšie a v niektorých krajinách (napr. India, Indonézia) to reálne mení retention metriky.

Skvelá časť: nie je čo konfigurovať. Stačí byť na SDK 55 alebo novšom s najnovším expo-updates a všetko funguje automaticky. Diffing prebieha na strane servera a klient dostane binary patch, ktorý sa aplikuje na aktuálny cached bundle. Ak diff zlyhá alebo je príliš veľký, klient sa fallbackne na plný bundle, neexistuje spôsob, ako aktualizáciu „zablokovať“ nefunkčným diffom.

Pre optimalizáciu veľkosti bundle sa pozrite aj na náš návod na optimalizáciu Time-to-Interactive v React Native. Bundle splitting a lazy loading znižujú aj základný bundle, ktorý sa fingerprintuje. Ak vás zaujíma širší kontext architektúry, pozrite si aj text o novej architektúre React Native s Fabric a TurboModules, ktorá ovplyvňuje to, čo sa smie posielať cez OTA.

EAS Update v CI/CD pipeline s GitHub Actions

Manuálne spúšťanie eas update z lokálneho počítača funguje pre malý projekt, ale nemá čo hľadať v produkcii s viac ako jedným vývojárom. Toto je minimalistický, ale produkciou preverený GitHub Actions workflow:

name: EAS Update
on:
  push:
    branches: [main]

jobs:
  publish-update:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - name: Nainštaluj závislosti
        run: npm ci

      - name: Nainštaluj EAS CLI
        run: npm install -g eas-cli

      - name: Spusti testy
        run: npm test -- --ci

      - name: Publikuj OTA aktualizáciu na production kanál (0 %)
        run: eas update --branch production \
             --message "${{ github.event.head_commit.message }}" \
             --rollout-percentage 0 \
             --non-interactive
        env:
          EXPO_TOKEN: ${{ secrets.EXPO_TOKEN }}

Kľúčové body: publikujeme s 0 % rolloutom a rollout zvyšujeme manuálne alebo iným workflow-om cez workflow_dispatch. Trigger na main vetvu znamená, že každý merge do main-u vytvorí kandidátsku publikáciu, ale žiadny používateľ ju ešte nevidí. fetch-depth: 0 je dôležité, pretože EAS Update potrebuje git históriu pre správne generovanie updateId.

V roku 2026 Expo tiež oficiálne odporúča EAS Workflows ako natívny CI/CD nástroj. Spúšťa sa priamo na Expo infraštruktúre bez potreby GitHub minutes. Pre menšie tímy to zjednodušuje veci; pre tímy, ktoré už majú investovanú GitHub Actions matriku, sa oplatí zostať pri nej.

Migrácia z CodePush na EAS Update krok za krokom

Ak vám ešte niekde beží starý CodePush kód (a je prekvapivé, koľko tímov ho stále má, lebo aplikácia „funguje“), toto je bezpečná migračná cesta.

1. Odstráňte react-native-code-push z package.json, Podfile, MainApplication.java a všetkých JS/TS súborov. Grep na codePush je váš priateľ.
2. Odstráňte CodePushDeploymentKey z Info.plist a strings.xml.
3. Nainštalujte expo-updates a spustite eas update:configure. Ak nemáte Expo, môžete použiť „bare workflow“ integráciu; funguje aj v čistom React Native projekte.
4. Mapujte CodePush deployments na EAS kanály: Staging na kanál preview, Production na kanál production. Zaveďte runtime versioning.
5. Skompilujte a distribuujte nový build. Toto je nevyhnutný krok, používatelia musia mať v ruke binárku, ktorá volá expo-updates, nie CodePush. Starí používatelia zostanú „zamrznutí“ na poslednej CodePush verzii, kým si neaktualizujú aplikáciu z obchodu.
6. Publikujte prvý OTA cez EAS a monitorujte prevzatie cez dashboard.

Prechodové obdobie zvyčajne trvá 4–8 týždňov, kým väčšina používateľov migruje na nový build. Podľa oficiálneho blogu Expo je táto cesta preverená stovkami tímov v roku 2025 a 2026 a EAS Update tím aktívne pomáha s migráciou pre platené accounty.

Najčastejšie chyby a ako sa im vyhnúť

Tieto sú zoradené podľa toho, ako často som ich videl v konzultačných engagementoch za posledný rok.

1. Zabudnutie na bump runtime verzie

Pridáte nový natívny modul, publikujete OTA a stará binárka nedokáže načítať bundle, ktorý ho volá. Fingerprint policy toto rieši automaticky, ale ak používate manuálny runtimeVersion, potrebujete disciplínu.

2. Publikovanie priamo na production bez preview

Toto je klasika. Vždy najprv publikujte na preview vetvu, otestujte na fyzickom zariadení a až potom cielite production. Preview build s development kanálom je jediný spôsob, ako reálne overiť správanie pred rolloutom.

3. Miešanie kanálov medzi build profilmi

Ak development build nechtiac dostane production kanál, môže dostať produkčnú aktualizáciu, ktorá spôsobí crash. Vyhraďte si čas a jasne definujte v eas.json, ktorý profil má ktorý kanál.

4. Netagovanie crash reportov s updateId

Ak Sentry alebo Bugsnag nevidí, ktorá presne OTA aktualizácia beží na zariadení, ktoré havarovalo, nedokážete debugovať. Nastavte tag automaticky pri štarte aplikácie:

import * as Updates from 'expo-updates';
import * as Sentry from '@sentry/react-native';

Sentry.setTag('updateId', Updates.updateId ?? 'embedded');
Sentry.setTag('channel', Updates.channel ?? 'none');
Sentry.setTag('runtimeVersion', Updates.runtimeVersion);

5. Prekročenie App Store review policy

Apple aj Google povoľujú OTA aktualizácie, ale jasne zakazujú „zásadné zmeny funkcionality“ mimo review procesu. Prakticky to znamená: neposielajte cez OTA nové UI flows, ktoré neboli v review verzii, a neaktivujte funkcie, ktoré by porušovali Guidelines. Feature flags áno, kompletné nové aplikačné módy nie. Pozrite si App Store Review Guidelines, sekciu 3.3.2, pre presné znenie.