Search across all documentation pages
EAS Update channel naming, runtime version policy, promotion workflow, and rollback triggers for Expo SDK 57. OTA updates are powerful and dangerous - JavaScript can reach production in minutes without store review. These rules separate safe OTA changes from native-breaking releases and define when to roll back.
eas update - wrong runtimeVersion strands users on stale bundles silently.eas update with crash monitoring and feature flags - OTA without observability is blind flight.Set explicit runtimeVersion policy in app.config: Use policy: "appVersion", "sdkVersion", or "fingerprint" consistently - document which policy the team uses in README.
runtimeVersion on eas build artifacts must match what eas update targets.runtimeVersion and hoping EAS guesses correctly across flavors.Bump runtime when native dependencies change: New native module, SDK upgrade, or config plugin change → new store build and new runtime - OTA alone cannot add native code.
Configure updates.url and project ID for EAS Update: extra.eas.projectId and updates.url in app.config - verify with npx expo config --type public.
projectId and channels per bundle ID.eas update:list shows recent bundles after a test publish.Use eas update --environment <name> on SDK 55+: Update runners load vars from the named EAS environment - local .env files are ignored, keeping OTA aligned with build env.
eas update --channel production --environment production..env.local.Check for updates on launch with a sane policy: expo-updates checkAutomatically and fallbackToCacheTimeout - balance freshness with offline startup.
Code signing for updates when required: Enable EAS Update code signing for high-assurance apps - verify signing cert rotation in runbook.
Channel names map to environments, not people: development, preview, staging, production - not jane-test or hotfix-tuesday.
eas.json build profiles assign channel per profile.Promotion flow is linear: development → preview (QA) → production - no skipping preview for "small" JS changes that touch payments or auth.
production update from a feature branch without preview soak.Preview builds pair with preview channel: QA installs EAS preview profile binary and receives OTA on preview channel - matches production behavior without store risk.
Production channel updates require two-person rule or CI-only publish: Human eas update --channel production from laptops is error-prone - prefer GitHub Action on tagged release.
eas update:list reviewed in release ticket.Version app.config version and store build numbers independently: Marketing version vs ios.buildNumber / android.versionCode - increment build numbers every store submission.
runtimeVersion: { policy: "appVersion" }, app version bumps affect OTA targeting.Feature flags gate risky OTA payloads: Remote flags can disable bad JS paths without a second OTA - flags are not a substitute for preview testing.
OTA-safe: JS, TS, assets, copy, styles, navigation structure: Pure JavaScript changes that do not call new native symbols.
Store-required: native modules, plugins, permissions, scheme, entitlements: Anything that changes ios/ or android/ output from prebuild.
Hermes bytecode and bundle size regressions can ship OTA - treat as release events: Large bundles slow startup - watch performance budgets (see Performance Budget Rules).
Database schema and API contract changes need backward compatibility: Mobile users skip updates - JS must tolerate old API responses until store adoption is high.
Do not OTA breaking changes to persisted local storage shape without migration: MMKV/SQLite schema bumps need graceful migration or version gate - bad migration bricks installs.
Emergency OTA still runs through preview when possible: True sev-1 may skip soak - document exception and require postmortem plus rollback verification within one hour.
Define rollback triggers before launch:
| Trigger | Owner | Action |
|---|---|---|
| Crash-free rate drops > X% vs baseline | Mobile on-call | Republish previous bundle or channel redirect |
| Auth/login failure rate spike | Backend + mobile | Rollback OTA + flag off |
| Payment success rate drop | Revenue + mobile | Immediate production rollback |
| P0 security issue in JS | Security + mobile | OTA fix or rollback within SLA |
Know how to roll back an EAS Update: Republish prior bundle ID to channel, or use EAS dashboard rollback - practice in preview quarterly.
Store rollback is slower - plan binary fallback: Keep previous store version available; phased rollout on App Store and staged rollout on Play Store when possible.
Monitor after every production OTA for 24 hours: Sentry, analytics, and API error dashboards - on-call watches without assuming success at publish time.
Runtime mismatch alerts: Users on old binaries who never receive updates - track expo-updates check failures and stale runtime versions in analytics.
Release checklist is two tracks: Store submission checklist (native, screenshots, review) and OTA checklist (preview soak, flags, rollback ID) - attach both to release tickets.
Post-release retrospective for any rollback: Update triggers, preview duration, or CI gates - rollbacks are free lessons if documented.
appVersion ties runtime to marketing version - simple for many apps. fingerprint hashes native project state - better when native changes without version bumps. Pick one policy, document it, and never mix inconsistently across flavors.
No - native crashes need a new store build. OTA fixes JavaScript errors and logic bugs only.
Minimum: development, preview, production. Larger orgs add staging. Avoid per-developer channels - use preview builds with branch-based updates instead.
On SDK 55+, eas update --environment uses EAS environment variables only - local .env is ignored on runners. Align with how eas build resolves env.
Mandatory for security fixes and breaking API contract changes. Optional banner for UI tweaks. Document UX in expo-updates reload strategy.
Flags disable code paths in already-shipped bundles - faster than OTA rollback for logic errors. Flags do not replace preview testing or server authorization.
24 hours minimum for auth and payment paths; shorter only with strong automated coverage and on-call coverage. Sev-1 exceptions documented post-hoc.
No - each bundle ID and EAS project needs distinct channels and runtime lines. Shared JS monorepo can publish per-app with separate eas update commands.
Use preview/dev client builds pointing at development channel. expo-updates dev settings can override update URL in controlled staging - not in production apps.
Store version, build numbers, OTA bundle ID, channel, last known-good rollback ID, feature flags touched, preview soak window, and dashboard links.
Strongly recommended - tags trigger eas update with environment production. Break-glass laptop publish requires second approver and postmortem.
SDK upgrade changes native binaries - new store build, new runtimeVersion line. Old runtimes stop receiving updates on the new native line; plan user upgrade messaging.
Expected - users on old store builds stay on their runtime channel until they upgrade the binary. Track runtime distribution and enforce minimum native version when needed.
Stack versions: This page was written for React 19.2.3, React Native 0.86.0, and Expo SDK 57 (
expo~57.0.4).
Reviewed by Chris St. John·Last updated Jul 9, 2026