EXPO OTA questions


First, thank you to all the people working on this amazing project. We love it, we even started building our customers apps with Expo and switching to it (except for some who require native code only features).

Expo has gotten bigger for sure and we almost found an answer for most of the problems we face. that being said, i have an important question that i need a clear answer for as it’s very sensitive and there is no room for try-and-fail, so if these questions sounds lazy, believe me I’ve been doing research for the past 3 days over it, but if there are resources that can help answer the question clearly please let me know.) with thanks to everybody in advance:

  1. I didn’t know that Expo have OTA feature implemented, i thought it was something that can be added if needed. but after publishing the customer app on the iOS and android store, i was rebuilding and resubmitting the app to the stores over small changes, so that is not required any more, which is great. but I had some testers use Expo Client to test the latest changes on the code and as it turns out, these changes are effecting the people who are downloading the standalone apps from the stores.

How can I allow people with Expo client to see the changes i’m testing, before updating to the standalone? is there even a way to do so? (my final thought was to establish a new project for testing purposes and once everything is fine, i move it to the production one and republish it, is this the proper way to do this, or is there an on/off to this.

  1. I read the list of situations that requires rebuilding and resubmitting the app to the stores, but i’m not a node expert, so my questions is: when i run npm install -g exp, or add a new library through npm install, do i have to rebuild the app, or will these changes be also included in the OTA process?

Thank you in advance,
Rafet Khallaf

Do you have an idea about any of the 2 questions i mentioned @dikaiosune ? Any guidance will be appreciated!

Hi! To let your testers see new code before it’s published to the stores, I’d recommend using Release Channels. This would allow you to, for example, have a staging channel which your testers load, and a production channel that is used by your app store binaries. When you want to move your code to production, you’d republish to your production channel (I believe we will eventually allow you to atomically promote your app from channel to channel, but I’m not sure when that’ll be built). You can disable OTA downloads on iOS using the ios.isRemoteJsEnabled flag in app.json.

In general, you should only need to rebuild your binaries (with exp build) whenever something in app.json changes, or when you want to re-bundle the cached/offline initial load assets (the JS code that’s included in the binary for first load, in the future any offline assets that have been bundled). Adding a new npm package shouldn’t require running a fresh binary build.

Does that answer your questions?


On Android, if you publish a v1 of your APK with v1 of the JS, install and run v1, then publish a v2 of your APK with a new v2 JS bundle, and install v2, does it indeed upgrade to the latest bundle in the v2 APK, or does it still have to download v2 of the JS from Expo?

In my experience (which has all been sideloading so far- haven’t yet deployed to Play Store), Even after installing v2 of the APK, it still notified that there was an update for the JS, and I had to restart the app in order to get the new JS bundle.

The one time this didn’t happen is when I installed v1, didn’t run it, and then installed v2. That time, the first time I ran, I started off with v2 of the JS.

Some context behind my example: we’re trying to ensure we can force Android to the latest JS in the case of a critical update. Expo OTA updates are great, but we have no guarantee when someone will close the app, so no guarantee that they’ll get the update in a timely manner. So, we’d like to ensure that, if we deploy an update via the Play Store, we know the user will get the update. We tried using the update listener to force a reload to ensure this, but ran into a showstopper issue here: Android - calling Util.reload() causes Image requests to be sent without cookies

1 Like