Over-the-Air Updates and Your Release Routine

A user reports that Trailhead rejects “8,4” as a distance on her German phone. You fix the parser in five minutes. Without anything else, getting that fix to her means a new build, a submission and a review, then waiting for her to update. EAS Update shortens that to one command: it publishes new JavaScript and assets, and installed copies of Trailhead download them the next time they start.

How an update reaches a phone

A release build contains two things: the native app (compiled Swift, Kotlin and C++, including every native module) and an embedded JavaScript bundle. An update replaces only the second part. When the app launches, expo-updates checks the server for a newer bundle for its channel and runtime version. By default it starts immediately with the code it already has, downloads the new update in the background, and uses it on the next launch. Startup never waits on the network, which matters for an app opened at a trailhead with one bar of signal.

Set it up once, then make new builds so they include the update configuration:

eas update:configure

This adds the update URL and a runtimeVersion to your app config. Then give each build profile a channel in eas.json:

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

Publishing an update is one command:

eas update --channel production --message "Accept comma decimals in distance"

Production builds pick it up on their next launch. Publish to preview first, check it on your testers’ builds, then publish the same code to production.

What can and can’t go over the air

This is the JavaScript-versus-native distinction from the second lesson of the course, now with consequences. If a change touches native code or native configuration, an update can’t deliver it.

Runtime versions keep updates compatible

Imagine Trailhead 1.1 adds expo-camera. Its JavaScript imports a native module that 1.0 builds don’t contain. If 1.0 users received that update, the app would crash when it touched the camera. The runtime version prevents that: every build and every update carries one, and an update only applies to builds with the same runtime version.

{
  "expo": {
    "version": "1.1.0",
    "runtimeVersion": { "policy": "appVersion" }
  }
}

With the appVersion policy, the runtime version is your app’s version, so you raise version whenever native code changes, and 1.0 and 1.1 builds stop sharing updates. The fingerprint policy computes a hash of the native parts of your project instead, so the runtime version changes automatically when native code does. Either works; pick one and understand it.

When an update goes wrong

Updates reach many users quickly, which cuts both ways. If one misbehaves, roll back:

eas update:rollback

It walks you through returning the channel’s branch to a previous update or to the code embedded in the build. Users get the rollback on their next launch, the same way they got the update. That’s why every update deserves the same care as a release: run your tests, publish to preview, open it on a real phone, then publish to production. Both stores allow updating JavaScript this way for bug fixes and improvements; using it to change what the app fundamentally does, without review, is against their rules.

A release routine that holds up

Here’s a rhythm that works for a small team:

• JavaScript fixes: test, eas update to preview, check, then to production. Same day.
• Native changes or new features: raise version, production build, TestFlight and internal track, review, release. Planned, every few weeks.
• Every release: watch crash reports for the first day, and keep eas update:rollback ready.

Where you are now

You started with a single Text in an Expo project. Trailhead now has lists that stay fast, tabs and stacks with typed params, a form that handles the keyboard, data in SQLite and a token in secure storage, GPS tracking, photos, reminders, tests, store builds and a way to fix bugs the same afternoon. More importantly, you know where React Native differs from the web and why: native views, two threads, no cascade, permissions that can be refused, and two kinds of change, JavaScript and native.

Good next steps: add Reanimated and react-native-gesture-handler for richer interactions, TanStack Query for server data, and Maestro for a couple of end-to-end tests. Then ship something small to real users and learn from what they do with it.