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.
\nA 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:
\neas update:configureThis adds the update URL and a runtimeVersion to your app config. Then give each build profile a channel in eas.json:
{\n \"build\": {\n \"preview\": { \"distribution\": \"internal\", \"channel\": \"preview\" },\n \"production\": { \"autoIncrement\": true, \"channel\": \"production\" }\n }\n}Publishing an update is one command:
\neas 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.
Ships with eas update | \nNeeds a new build and store release | \n
|---|---|
| Components, screens, styles, logic | \nAdding or upgrading a native module | \n
| Images and fonts bundled with the JavaScript | \nPermission descriptions and other native config | \n
| Bug fixes and copy changes | \nApp icon, splash screen, bundle identifier | \n
| New screens built from existing native modules | \nExpo SDK upgrades | \n
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.
\nImagine 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.
{\n \"expo\": {\n \"version\": \"1.1.0\",\n \"runtimeVersion\": { \"policy\": \"appVersion\" }\n }\n}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.
Updates reach many users quickly, which cuts both ways. If one misbehaves, roll back:
\neas update:rollbackIt 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.
Here’s a rhythm that works for a small team:
\neas update to preview, check, then to production. Same day.version, production build, TestFlight and internal track, review, release. Planned, every few weeks.eas update:rollback ready.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.
\n","toc":[{"id":"sec-1","text":"How an update reaches a phone","level":2},{"id":"sec-2","text":"What can and can’t go over the air","level":2},{"id":"sec-3","text":"Runtime versions keep updates compatible","level":2},{"id":"sec-4","text":"When an update goes wrong","level":2},{"id":"sec-5","text":"A release routine that holds up","level":2},{"id":"sec-6","text":"Where you are now","level":2}],"takeaways":["EAS Update replaces your app’s JavaScript bundle and assets on installed builds, without a new binary or store review.","Only JavaScript and asset changes can ship over the air; new native modules, permission strings, icons and SDK upgrades need a new build.","A build’s channel decides which updates it receives, and its runtime version decides which updates are compatible with its native code.","By default an update downloads in the background and applies on the next launch.","When an update misbehaves,eas update:rollback returns users to a previous update or to the code embedded in their build."],"further":[{"title":"EAS Update introduction","url":"https://docs.expo.dev/eas-update/introduction/"},{"title":"How EAS Update works","url":"https://docs.expo.dev/eas-update/how-it-works/"},{"title":"Runtime versions and updates","url":"https://docs.expo.dev/eas-update/runtime-versions/"},{"title":"Rollbacks","url":"https://docs.expo.dev/eas-update/rollbacks/"}],"quiz":[{"q":"Which Trailhead change can reach users with eas update alone?
expo-camera to scan QR codes on trail markers.","why":"A new native module must be compiled into the binary, so it needs a new build and a store release."},{"text":"Fixing the comma bug in parseDistanceKm and rewording an error message.","why":"Correct. Both are JavaScript changes, which is exactly what an update replaces."},{"text":"Changing the location permission description in app.json.","why":"Usage descriptions are compiled into the native configuration; they change only with a new build."},{"text":"Upgrading to the next Expo SDK.","why":"An SDK upgrade changes native code and the runtime version, so it always needs new builds."}],"answer":1},{"q":"You publish an update to the production channel. A user opens Trailhead an hour later. With default settings, when do they see the fix?
","options":[{"text":"Immediately; the app blocks on the splash screen until the update downloads.","why":"By default the app launches with the code it already has, so a slow network never delays startup."},{"text":"Only after they reinstall the app from the store.","why":"Updates install without the store. That’s the whole point of EAS Update."},{"text":"On the next launch after this one; the update downloads in the background during this session.","why":"Correct. The app checks on launch, downloads in the background, and applies the update the next time it starts."}],"answer":2},{"q":"Users on Trailhead 1.0 (built before you added expo-camera) and 1.1 (built after) both use the production channel. You publish a JavaScript update that imports expo-camera. What keeps 1.0 users from crashing?
appVersion or fingerprint policy, native changes produce a new runtime version, and updates only reach compatible builds."},{"text":"Nothing; you must publish separate updates by hand and hope the right users get them.","why":"Runtime versions exist precisely so you don’t have to rely on hope."},{"text":"EAS Update installs the missing native module along with the JavaScript.","why":"Updates can’t add native code. That’s why compatibility checks matter."}],"answer":0}],"exercise":{"kind":"choice","multiple":true,"options":["copy-fix","reducer-bug","new-screen","add-sdk-module","icon","permission-text","new-image"],"correct":["copy-fix","reducer-bug","new-screen","new-image"],"title":"Update or new build?","prompt":"Trailhead 1.2 is live with runtimeVersion set to the appVersion policy. The team’s list for this week is below. Select every change you can ship to existing 1.2 users with eas update alone, without a new build or store review.
Text, logic, new screens built from modules already in the binary, and images bundled with the JavaScript are all part of the update bundle, so they ship with eas update. A new native module like expo-haptics needs to be compiled in; the app icon and permission descriptions live in native configuration the OS reads from the installed binary. Those three need a new version, a production build and a store release.
hikesReducer so editing a hike’s date re-sorts the list.","why":"Update. Pure JavaScript logic, the ideal over-the-air fix."},"new-screen":{"text":"Add a yearly stats screen built only from View, Text and FlatList.","why":"Update. New screens are fine as long as every native module they use is already in the build."},"add-sdk-module":{"text":"Add expo-haptics so the Save button vibrates gently.","why":"New build. A native module that isn’t in the installed binary can’t arrive in an update."},"icon":{"text":"Replace the app icon with the new logo.","why":"New build. The home-screen icon is part of the installed app package, not the JavaScript bundle."},"permission-text":{"text":"Clarify the location permission description in the expo-location plugin options.","why":"New build. Config plugin options are written into native configuration when the app is built."},"new-image":{"text":"Swap the empty-state illustration for a new PNG imported with require().","why":"Update. Images bundled through the JavaScript bundler are assets that updates include."}}},"words":825,"readMinutes":4}