EAS + expo-updates

[ec_raphael]

I’m just looking for some opinions on best practices using expo-updates and eas. Until recently I’ve been using expo build:<platform> with --release-channel <channel> and found that practical, because we automatically created release channels based on the semver major/minor version. Essentially, over-the-air updates would happen for patches, but not minor releases. I forget my specific reasoning, but I think I just felt more comfortable only releasing things like minor UI changes OTA.

Anyway, I quite like the idea of having a release channel based on a version, but that becomes more of a pain with a static json file. Looking through expo docs, I’m wondering if I should just simplify and do “production” and “staging”?

[jonsamp]

Hi @ec_raphael,

This is a really good question!

Currently, as you’ve noted, there’s no way for eas.json to automatically read the version number from app.json to update eas.json’s releaseChannel property. So, to continue what I assume you’re doing, when you update app.json’s version property, you’d also need to update eas.json’s releaseChannel properties to match. Then, you could create new builds with the new release channels, and then run expo publish --release-channel ... to send updates.

With that, it sounds like your flow might work better with updating app.json’s runtimeVersion property. This property signifies the state of the “native layer” of the code, and guarantees that an update is compatible with the build it gets run on.

So, an example: Let’s say you set runtimeVersion to "1.0" for your first release. You could make builds with releaseChannels like staging and production if you want. Once you’ve distributed the builds to end-users, you could send changes with expo publish --release-channel .... Each time you publish with Expo CLI, it will assign the runtimeVersion currently in app.json to the update automatically.

Now, we’d have some builds with a runtime version of 1.0, and also some updates with the same runtime version. Since they have matching runtime versions, we know that they are compatible, and that the update can run on the build.

When the next feature/bug fix runs around that requires a new build, you could update the project’s runtimeVersion to 2.0 (for example). Then you’d be ready for another round of builds, and all subsequent updates would be compatible with the 2.0 runtime version.

Doing this, release channels now serve another purpose: to help you distribute builds to different groups of end-users. Often teams will have staging/production release channels, which are distributed to test end-users and production/public end-users.

---

We are currently working on the next generation of our updates service. It’s faster, and even more flexible. I wrote a doc (that only works with our new EAS Update service) on how teams deploy their apps, if it helps contextualize different approaches: Deployment patterns - Expo Documentation

[ec_raphael]

Awesome, thanks!