How to Support Over-the-Air Updates on Multiple Expo SDKs in Parallel
One thing to keep in mind when updating Expo SDKs
Expo is fantastic. It helps you develop, build, and deploy iOS, Android, and web apps — from the same code base.
It builds the binaries for both Android and iOS on its servers and provides support for the release channels and the over-the-air (OTA) updates.
The OTA updates work for any published changes to the JS bundle. You add the new feature to the app, run the Expo build, and publish. And that’s it. Users get the update right away on their devices — in the background and without updating the native app. Everything looks great so far!
Upgrading the Expo SDK
When you decide to upgrade the Expo SDK, there’s one thing you must remember: The SDK upgrade requires the native app to be updated on the application store (App Store, Google Play).
To get the new bundle via an OTA update, the SDK on the installed app must match the published one. But there’s no guarantee all users install updates immediately. And that’s the thing.
This is the flowchart that describes how the Expo determines which release to return to a user:
You can find more details about the publishing process here.
The case is that the native app built with the older SDK won’t receive any OTA updates for any subsequent SDK release until the user updates the native app.
Yeah, I understand. You might just want to communicate that the user should update the app — deploy a subtle “Please update the app” banner on the old version and forget about the thing.
Fair enough. That’s OK for most cases.
Deep down, though, you may realize that what you really want is to be able to release any security and stability patches for the old versions as well. You may also want the ability to add some urgent feature that displays the CTA button for the new service you added, let’s say, because of the pandemic.
You can just assume you’ll only support the latest version.
I’d suggest you check the application statistics. Specify the percentage threshold of the users you want to cover with updates. Based on that, define the exact SDK versions you have to support.
Create a branch from
main, right before the SDK upgrade. If it’s too late, use the last commit before the upgrade.
$ git switch main; git switch -c main-expo-sdk-36.
Merge any feature branch to
main as usual. Additionally, apply the feature to the other SDK branch as well. Assume you want to merge the CTA button feature from the
(main) $ git merge feature/cta-button
(main) $ git push
(main) $ git switch main-expo-sdk36
(main-expo-sdk-36) $ git merge feature/cta-button
(main-expo-sdk-36) $ git push
The process remains unchanged, except that you have to do the same also for every
main-expo-sdk-* branch. It can be deployed to the same release channel (see the diagram above).
Using the same source folder is time-consuming.
You have to reinstall node modules when switching between the SDK versions. This can be a pain if you want to perform several updates.
The solution is to create multiple project instances, one for each version of the SDK you’ll support. This is explained in the next section.
Clone the repo to a different folder(s), and work on the
main-expo-sdk-* branches there. Assume you have a
my-app app, and you want to support SDK 36.
# clone the same repository to my-app-sdk-36
$ git clone git@server:my-app.git ~/repos/my-app-sdk-36;# it should be a new folder here
$ ls ~/repos;
my-app-expo-sdk-36# enter the new folder and switch the branch to the SDK
$ cd my-app-expo-36;
$ git switch main-expo-sdk-36;
This the solution to reach most of the users with urgent updates.
When you upgrade the Expo SDK that doesn’t mean every device got the update right away. The subsequent OTA updates wono’t work for the devices with older SDKs.
This is OK for most cases, but now you’re prepared for other scenarios as well.