EAS Update 2026: Komplett guide till OTA-uppdateringar i React Native

Uppdaterad: 16 juni 2026

EAS Update är Expos tjänst för Over-the-Air-uppdateringar (OTA) som levererar nya JavaScript-buntar och tillgångar direkt till installerade React Native-appar utan en ny butiksgranskning. När Microsoft stängde CodePush den 31 mars 2025 blev EAS Update standardalternativet för OTA i React Native-ekosystemet. Den här guiden visar hur du sätter upp EAS Update i Expo SDK 55, hanterar kanaler och brancher, konfigurerar runtime-versioner med fingerprinting, gör säkra rollbacks och migrerar bort från CodePush. Jag har själv kört det här på två appar i produktion sedan SDK 51, så det mesta kommer från egna misstag.

• EAS Update fungerar med både Expo-projekt och bare React Native (via expo-updates-modulen) från och med SDK 50+.
• Endast JavaScript, bilder och andra JS-tillgångar kan uppdateras OTA. Native ändringar kräver en ny butiksversion.
• Runtime-versioner (helst med policy: "fingerprint" i SDK 53+) avgör vilken native build som tar emot vilken update.
• Channels mappar appbuilds (preview, production) till update-brancher. eas update --branch production publicerar en bunt.
• Rollbacks görs med eas update --branch production --republish eller via dashboarden, ingen butiksgranskning behövs.
• CodePush togs ur drift 31 mars 2025. Expo publicerade ett officiellt migreringsverktyg och dokumentation.

Vad är EAS Update och hur fungerar det?

EAS Update är en värdtjänst från Expo som lagrar och levererar uppdaterade JavaScript-buntar samt tillgångar (bilder, fonter, ljud) till installerade appar via Expos globala CDN. När en användare öppnar appen frågar expo-updates-modulen servern om det finns en nyare update som matchar enhetens runtime-version och channel. Hittas en, laddas den ned i bakgrunden och appliceras vid nästa kallstart, eller omedelbart om du anropar Updates.reloadAsync().

Tjänsten ersatte den experimentella Expo Updates Classic-tjänsten 2022 och blev produktionsklar 2023. Den fungerar med både hanterade Expo-projekt och bare React Native-appar via npm-paketet expo-updates, och stöder Android, iOS samt (sedan SDK 53) webb i begränsad form.

Viktigt att förstå: EAS Update kan endast leverera JS, JSON och tillgångar som ingår i Metro-bundeln. Allt som rör Java/Kotlin/Swift/Objective-C, AndroidManifest, Info.plist, ikoner, splash screens eller nya native-paket kräver en ny build via EAS Build och en ny butikssläpp. Det är en gräns som folk snubblar på minst en gång.

EAS Update jämfört med EAS Build

Två tjänster med liknande namn förvirrar nya användare. Tabellen nedan klargör vad var och en gör, och när du behöver båda.

Egenskap	EAS Update	EAS Build
Vad levereras	JS-bunt och tillgångar	Native binär (.ipa, .apk, .aab)
Distribution	Direkt till installerad app	App Store, Google Play, intern
Granskningstid	Ingen, sekunder	1–48h hos butikerna
Native ändringar	Stöds inte	Krävs alltid
Typisk paketstorlek	1–5 MB diff	30–100 MB
Prissättning	Per månads-aktiv användare	Per build-minut
Användning	Bugfixar, små features	Nya native-paket, butikssläpp

I praktiken används de tillsammans. Du gör en EAS Build var fjärde till sjätte vecka för att uppdatera native lager och SDK, och däremellan släpper du fem till tio EAS Updates med JS-fixar, copy-ändringar och feature-flaggor. Arbetsdelningen är samma mönster som CodePush-användare är vana vid, fast med tightare Expo-integration.

Installation och konfiguration steg för steg

Antagandet är ett befintligt Expo SDK 55-projekt, eller en bare React Native-app med expo-modules installerade. Börja med att logga in mot din Expo-organisation och installera EAS CLI globalt.

npm install -g eas-cli
eas login
eas init --id <din-projektid-eller-skapa-ny>

Installera sedan expo-updates och kör Expos konfigurationskommando som skriver in nödvändiga nycklar i app.json och native-projekten:

npx expo install expo-updates
eas update:configure

Efter det innehåller app.json ett updates-block och en runtimeVersion-policy. Skapa ett eas.json som binder builds till update-channels:

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

Bygg appen en gång per channel så att binären innehåller rätt channel-värde inbakat. Därefter kan du publicera en update när som helst:

# Bygg en produktionsbinär (en gång per native-ändring)
eas build --profile production --platform all

# Publicera en JS-only update till produktion (när som helst)
eas update --branch production --message "Fixar krasch i checkout"

Inom någon minut hämtar alla produktionsenheter den nya bunten vid nästa kallstart. För djupare integration med navigationsflödet i din app, kombinera det här med en strategi från vår guide om Expo Router v7 och filbaserad navigering. Du kan exempelvis tvinga omladdning först när användaren når rotrutan, så att man aldrig avbryter ett pågående flöde.

Runtime-versioner och fingerprint i SDK 55

Runtime-versionen är EAS Updates viktigaste säkerhetsmekanism. Den representerar det native-kontrakt som JS-bunten förväntar sig: kompatibla native-libs, modulversioner, permissions. En update levereras endast till enheter med matchande runtime-version, vilket förhindrar att en JS-bunt som anropar en ny native-modul kraschar äldre binärer.

Sedan Expo SDK 53 (släppt april 2025) rekommenderas fingerprint-policyn istället för manuell versionsnumrering. Fingerprint hashar alla native-källor och beroenden vid byggtid och genererar runtime-versionen automatiskt:

// app.json
{
  "expo": {
    "runtimeVersion": { "policy": "fingerprint" },
    "updates": {
      "url": "https://u.expo.dev/<projektid>",
      "fallbackToCacheTimeout": 0
    }
  }
}

När du lägger till en native-modul (t.ex. react-native-mmkv) ändras fingerprintet automatiskt, och nya updates riktas bara till builds gjorda efter den ändringen. Äldre installationer fortsätter att få äldre, kompatibla updates tills användaren uppdaterar via butiken.

Kanaler, brancher och rollout-strategier

Channels och branches är två koncept som ofta blandas ihop. Channels är taggar som bakas in i en build (i eas.json). Branches är strömmar av updates på servern. En channel mappas alltid mot en branch, och du kan peka om mappningen utan att bygga om binären, vilket är grunden för promotion- och canary-flöden.

Ett vanligt produktions-setup ser ut så här:

• preview-channel → preview-branch (interna testare)
• production-channel → production-branch (slutanvändare)
• canary-branch (10% av användarna via dashboard-rollout)

För att kampanjpublicera en update bara till 10% av produktionsenheter använder du EAS dashboardens rollout-funktion, som introducerades i januari 2026. Du publicerar normalt till en separat branch och pekar sedan produktions-channelen att hämta 10% från canary, 90% från stable. Övervaka kraschfrekvensen i din APM (Sentry, Bugsnag) och öka procenten gradvis.

# Publicera till canary
eas update --branch canary --message "Ny checkout-flow (canary)"

# Promovera canary till produktion när metriker ser bra ut
eas channel:edit production --branch canary
# eller via dashboard: production channel, 10% canary, 90% stable

Mönstret påminner om feature flags, fast det opererar på hela JS-bundeln. Det är användbart när en ändring rör många filer eller är svår att gate:a kodmässigt.

Hur gör jag rollback av en EAS Update?

Rollback är en av EAS Updates starkaste fördelar jämfört med butikssläpp. En defekt update kan plockas tillbaka inom sekunder och alla nya installationer hämtar den föregående bunten. Det finns tre primära strategier.

1. Republikera en tidigare update

Den snabbaste metoden. Den publicerar om en specifik tidigare update som "ny" och får alla enheter att hämta den.

eas update:list --branch production
# Hitta update-iden du vill återgå till
eas update:republish --group <update-group-id> --branch production

2. Rollback-to-embedded

Tvingar enheter att återgå till JS-bunten som ursprungligen ingick i binären (den från App Store). Användbart när alla OTA-updates har problem.

eas update --branch production --message "Rollback till embedded" --rollback-to-embedded

3. Channel-pekning

Peka produktions-channelen till en helt annan, stabil branch. Bra när du har en känd-stabil branch sparad.

eas channel:edit production --branch production-stable

Oavsett strategi: bekräfta att rollbacken nått användarna genom att kolla Updates.createdAt i din Sentry-eventdata eller en analyttagg. För djupare insikt i hur du fångar krasch-spikar efter en publicering, se vår genomgång av felsökning i React Native 2026.

Migrera från CodePush till EAS Update

Microsoft stängde CodePush-tjänsten den 31 mars 2025, vilket lämnade tusentals appar utan OTA-leverans. Expo publicerade ett officiellt migreringsverktyg och dokumentation i september 2024 för att underlätta övergången. Några kärnskillnader att hantera:

• SDK-byte: Ta bort react-native-code-push och installera expo-updates.
• Wrapper-borttagning: CodePush wrappade din root-komponent med codePush(). EAS Update kräver ingen wrapper, modulen körs vid app-start.
• Deployment → channel: CodePushs "Staging/Production" blir EAS-channels "preview/production".
• Mandatory updates: CodePushs mandatoryInstallMode motsvarar att anropa Updates.reloadAsync() direkt efter Updates.fetchUpdateAsync().

// Före (CodePush)
import codePush from "react-native-code-push";
export default codePush({
  checkFrequency: codePush.CheckFrequency.ON_APP_RESUME
})(App);

// Efter (EAS Update)
import * as Updates from "expo-updates";
import { useEffect } from "react";

export default function App() {
  useEffect(() => {
    async function check() {
      const update = await Updates.checkForUpdateAsync();
      if (update.isAvailable) {
        await Updates.fetchUpdateAsync();
        await Updates.reloadAsync();
      }
    }
    check();
  }, []);
  return <RootNavigator />;
}

För hjälp med själva migreringen är Expos officiella CodePush-till-EAS-guide oslagbar. Den täcker alla edge cases inklusive bare React Native och hybridappar. Jag följde den när vi migrerade en hybridapp förra hösten, och det enda som krävde extra handpåläggning var en gammal native-modul som hade en egen update-mekanism.

Prissättning, gränser och övervakning

EAS Update prissätts per månadsaktiv användare (MAU), räknat som unika enheter som checkade efter en update minst en gång under månaden. Per juni 2026 ser planerna ut så här:

• Free: 1 000 MAU, 100 GB bandwidth/mån. Bra för utveckling och små appar.
• Production ($99/mån): 50 000 MAU inkluderade, $0,005 per ytterligare MAU.
• Enterprise: Custom. Egen CDN-region, SLA, SOC 2-rapport.

Bandbredd faktureras separat över 100 GB på Free-planen men är obegränsad på Production. Updates komprimeras med Brotli och differential-uppdateras: bara ändrade chunks skickas, vilket håller en typisk update under 500 KB även för stora appar. Det är förvånansvärt effektivt på dåliga nät.

Övervakning sker via EAS dashboarden där du ser deploys, download-frekvens per channel, och fel rapporterade av expo-updates-modulen själv. Kombinera med Sentry för att korrelera krasch-spikar med specifika update-IDn. Se vår guide om React Native-prestandaoptimering för fler tips på instrumentering. Som referensdokumentation rekommenderar jag också Expos officiella EAS Update-dokumentation, som hålls löpande uppdaterad med varje SDK-release.

Vanliga fel och felsökning

Tre fel står för 80% av supportbiljetterna kring EAS Update.

"No update available" trots publicering

Nästan alltid en runtime-version-mismatch. Kör npx expo-doctor och jämför fingerprintet med det som finns på servern. Skiljer de sig måste du bygga om binären. Jag hittade den här buggen genom att rakt av jämföra två hash-strängar i en terminal, ingen magi.

Update laddas ner men tillämpas aldrig

Inträffar när appen aldrig kallstartas. Den fortsätter köras i bakgrunden på iOS i upp till 30 minuter. Lös det genom att anropa Updates.reloadAsync() manuellt när användaren navigerar till en säker plats (inte mitt i en transaktion).

"Manifest fetch failed" på Android

Cleartext HTTP-trafik blockeras i Android 9+. Säkerställ att updates.url börjar med https:// och att android.usesCleartextTraffic inte är satt till false i en proxy-konfiguration.

För svårdiagnostiserade fel, sätt EXPO_UPDATES_LOG_LEVEL=debug via en konfigurationsfil och granska enhetsloggar. Modulen är extremt verbose när debug är på, vilket är precis det man vill ha mitt i en incident.

Vanliga frågor

Är EAS Update gratis att använda?

Ja, upp till 1 000 månadsaktiva användare och 100 GB bandbredd per månad på Free-planen. För större appar kostar Production-planen $99/månad och inkluderar 50 000 MAU.

Kan jag använda EAS Update med bare React Native?

Ja. Sedan Expo SDK 50 fungerar expo-updates i bare workflow utan att hela projektet behöver konverteras. Installera expo-modules-paketet och kör eas update:configure för att konfigurera native-projekten.

Vad ersätter CodePush?

EAS Update är den officiella efterträdaren och rekommenderas av både Microsoft och Expo. Migreringen är direkt: byt ut react-native-code-push mot expo-updates, mappa deployments till channels och ta bort CodePush-wrappern runt root-komponenten.

Kan jag uppdatera native-kod med EAS Update?

Nej. EAS Update levererar endast JavaScript, JSON och tillgångar som ingår i Metro-bundeln. Alla ändringar i Java, Kotlin, Swift, Objective-C, AndroidManifest, Info.plist eller nya native-paket kräver en ny EAS Build och en butikssläpp.

Hur lång tid tar det innan användare får en update?

Det beror på din checkAutomatically-inställning. Default är ON_LOAD: appen kollar vid varje kallstart, laddar ner i bakgrunden och tillämpar updaten vid nästa start. För omedelbar tillämpning anropar du Updates.reloadAsync() direkt efter fetchUpdateAsync().