CI/CD and Over-the-Air Updates

Three things in that file are worth pulling out.

npm ci, never npm install. npm ci deletes node_modules and installs exactly what package-lock.json pins, failing outright if the lockfile and package.json disagree. npm install is allowed to resolve a newer matching version and rewrite the lockfile, which is precisely the non-reproducibility CI exists to eliminate.

The iOS job is on macOS and the Android job is not. Compiling and signing an iOS app requires Xcode, which requires a macOS runner — there is no way around it, and GitHub bills macOS runner minutes at a multiple of Linux minutes, which is the single largest cost lever in a React Native pipeline. Android is the opposite case: an emulator needs hardware virtualization, and on GitHub-hosted runners KVM is available on Linux, so the Android emulator job runs faster and cheaper on ubuntu-latest than it would on macOS. Splitting the two platforms across two runner types is not an accident of this example, it is the cost-optimal arrangement.

Detox and Maestro are both here on purpose. Testing wrote the same "add a place and see it in the list" journey twice, once as a Detox flow and once as a Maestro flow; this workflow runs the Detox version against iOS and the Maestro version against Android. A real project usually picks one and runs it on both platforms — showing both here is what makes the two runner shapes visible in a single file.

A React Native CI run downloads three separate dependency universes, and each has its own cache with its own correct key:

The key discipline is the same in all three cases: key the cache on the lockfile, so any dependency change produces a new key and any unchanged tree hits the cache. Keying on a branch name or a date instead produces the two failure modes that make caches worse than useless — a stale cache serving the wrong dependency version, or a cache that never hits.

A cache does not make the build incremental, only the download. A React Native CI run that still recompiles the whole Android project on every push is doing the expected thing; the cache is there so it does not also re-download the Android toolchain every time.

EAS Workflows are Expo’s own CI/CD layer, configured as YAML files under .eas/workflows/ and run on Expo’s infrastructure with eas workflow:run. The appeal is that the build, submit, and update steps are first-class job types rather than shell commands: a job declares type: build and a profile from the same eas.json Building and Publishing already established, and EAS handles the macOS machine, the signing credentials, and the artifact storage.

The same file shape covers the store route: a type: build job with params.profile set to production, followed by a type: submit job that takes the build’s artifact and hands it to App Store Connect or the Play Console. Because EAS already holds the signing credentials for the project, no certificate or key material appears anywhere in the workflow file.

The trade-off is the usual managed-service one. EAS Workflows removes an entire class of infrastructure work — nobody maintains a macOS runner, nobody rotates a signing certificate into a CI secret — at the cost of running the most sensitive part of the pipeline on someone else’s machines, and of being tied to Expo’s own build system.

Fastlane is the opposite answer: a Ruby toolchain of actions and lanes that runs wherever you run it — a GitHub Actions runner, a self-hosted Mac mini, a developer’s laptop. It predates EAS by years, is not React-Native-specific, and is what a team with existing native iOS/Android pipelines almost always already has. Four of its actions carry most of the weight:

A lane is just a named sequence of those actions in fastlane/Fastfile:

Every credential in that lane — match’s passphrase, the App Store Connect API key, the Play service account JSON — is read from an environment variable with `ENV.fetch, which fails loudly when the variable is missing rather than silently building an unsigned artifact. In a GitHub Actions job those variables are populated from encrypted repository or environment secrets, interpolated into the job’s env block through the workflow expression syntax and GitHub’s secrets context — never checked in, never passed on a command line where a process listing would show them, and automatically masked if something tries to print one. No key, certificate, passphrase, or service-account file belongs in the repository, in a lane, or in a log line; Security covers the same rule from the app’s side.

Two numbers change on every release and they change for different reasons. The version (1.5.0 in app.config.ts) is the human-facing marketing string shown in the store listing. The build number (iOS buildNumber / Android versionCode) is a monotonically increasing integer that both stores require to be strictly higher than any build already uploaded — reusing one is rejected at upload time, before review.

The workable arrangement is to make the first number a deliberate human act on a release branch and the second number automatic:

Both stores permit an installed app to download and execute new interpreted code — which is what a React Native JavaScript bundle is — subject to a condition that both express in similar terms: the downloaded code must not change the app’s primary purpose, must not introduce features the reviewed version did not have, and must not circumvent review, signing, or the store’s own payment rules. Apple’s App Review Guidelines and the Apple Developer Program License Agreement carry this on the iOS side; Google Play’s Device and Network Abuse policy carries it on Android. Both are worth reading in the original before relying on them, because both have been revised more than once.

What is not negotiable is the technical boundary, and it is the one that matters day to day: an over-the-air update can ship JavaScript and assets, and nothing else. It cannot add a native module, change a native dependency version, alter a permission string in Info.plist or AndroidManifest.xml, change an app icon, or touch anything compiled into the binary. Those all live on the other side of a store submission, described in Building and Publishing, and no amount of update tooling changes that.

A useful way to hold the line: if the change would survive being deleted from node_modules and reinstalled without re-running pod install or a Gradle sync, it is probably shippable over the air. If it involves a native module, it is not.

EAS Update is Expo’s hosted implementation of that idea, and it rests on three concepts that are easy to conflate:

The diagram is the whole model in one picture: the channel and branch decide which stream of updates a binary listens to, and the runtime version decides which updates in that stream it is allowed to load. Two binaries on the same channel can legitimately be running different JavaScript, indefinitely, because they were compiled from different native trees.

The channel is set per build profile, alongside the environment configuration the same profiles already carry:

Each of the three profiles gets its own channel, so an internal preview build and a store production build can never be served each other’s JavaScript even though they share a codebase. The matching side of the configuration lives in app.config.ts:

fallbackToCacheTimeout: 0 is the setting with the largest user-visible consequence: it tells expo-updates never to hold the splash screen waiting for a download, but to launch immediately with the bundle already on disk and fetch any new one in the background for the next launch. The alternative — a non-zero timeout — trades startup latency for update immediacy, on every cold start, for every user, whether or not an update exists. A background fetch with an explicit in-app prompt, as in the Hook below, gets the immediacy back without taxing startup.

Publishing is a single command, run from CI after a merge:

The reason to publish this way rather than pushing to everyone at once is that an over-the-air update is released in minutes, which means a bad one also reaches everyone in minutes — the store review queue, whatever else it is, is an accidental blast-radius limiter, and going around it means supplying your own.

In a bare React Native app — no Expo prebuild, native projects committed to the repository — expo-updates is installed as an ordinary native dependency and wired into AppDelegate and MainApplication so the native layer loads its bundle through the updates module instead of from the app package directly. Everything above still applies: the same channels, branches, and runtime versions, published with the same eas update command.

What a bare app more often wants is explicit control over when a downloaded update is applied, rather than silently at the next cold start. Places wraps that in a Hook:

Three decisions in that Hook are worth naming. The check is guarded by DEV and Updates.isEnabled, so it is inert in development and in any build where updates are switched off. Every failure path is swallowed into 'none' rather than surfaced as an error, because an app that cannot launch when the update server is unreachable is strictly worse than an app running last week’s JavaScript. And reloadAsync is never called automatically — a reload discards all in-memory state, so doing it while a user is halfway through AddPlaceScreen would throw away their work; the 'ready' state exists so Places can offer the reload at a moment the user chooses, the same way Modals, Alerts, and Progress handles any other interruption.

For most of React Native’s history, over-the-air updates meant Microsoft CodePush, delivered through Visual Studio App Center. Plenty of still-running production apps were built on it, so the migration is worth stating plainly rather than skipping.

App Center was retired, and with it the hosted CodePush service; the react-native-code-push client library is likewise retired and no longer the recommended path for a new project. Microsoft open-sourced the CodePush server so that teams depending on it could keep going, which leaves two routes off the hosted service:

The structural lesson generalizes past this one product: the ability to ship without a store release is valuable enough to be worth depending on, and therefore valuable enough to be worth being able to replace. A project that can point its update client at a different endpoint — self-hosted or another vendor — without rewriting its release process has bought itself the option that the App Center retirement demanded of everyone who had not.