16

I developed an app with React Native and distributed it with Expo. I published the final version into Google Play and Apple Store.

Some time later I discovered in Expo's docs on Publishing that expo publish allows you to create an OTA ("over the air") update that is built into Expo and updates the app automatically, according to this answer:

The standalone app knows to look for updates at your app's published url.

This I tested and worked very well.

However, now I see that people downloading the app from the stores (that is, either Google Play or Apple Store) apparently get the initial version of the app, not the updated one.

What is the exact workflow for the OTA updates? Do they go and "replace" the existing version in Google Play and Apple Store the first time they open it? Or do they need to open it over again to get the update?

And what exactly triggers the update of the app?

fedorqui
  • 275,237
  • 103
  • 548
  • 598

1 Answers1

15

We've been having similar problems. I can see two things which might be causing this in your case:

  • Check in app.json if updates.fallbackToCacheTimeout is set. If it's set, that's how long expo will try to download the latest update before showing the last downloaded version (which will be the initial version after initial download).
  • If you have a large update, expo will try downloading the update for 30s before showing the last version of your app.

Check here for more info: https://docs.expo.io/versions/latest/guides/configuring-ota-updates/

OTA updates do not replace the version downloaded from the app store, they are stored first in the device's cache before being run on app start after download. Source https://docs.expo.io/versions/latest/sdk/updates/

Update downloads are automatically triggered on app start, then, depending on the settings it will either wait (as long as updates.fallbackToCacheTimeout allows) before showing the app, or show it immediately.

You can force the app to run the latest update (if you have one waiting) by just force quitting the app, then restarting.

Hope this helps!

Jacob Sievers
  • 506
  • 4
  • 13
  • 1
    Oh, cool! I have `updates.fallbackToCacheTimeout` set to 0, which in your link I read as _This will allow your app to start immediately with a cached bundle while downloading a newer one in the background for future use_. – fedorqui Apr 10 '19 at 10:13
  • 1
    So to make it clear to me (I am new on this world of Expo): a brand new user who just downloaded the app from the app store or google play, will get the updated version _after_ they run it once and force quitted once? Would any setting allow the updated version to occur on the first opening of the app? – fedorqui Apr 10 '19 at 10:14
  • 1
    That was our issue as well :) Exactly! If you want to make sure people have the latest version (after downloading from app store or google play), remove `updates.fallbackToCacheTimeout` or set it to something reasonable (30s is a long time for an app to start) – Jacob Sievers Apr 10 '19 at 10:17
  • 1
    So with my current setting to 0 the update is run in the background and be ready next time... In your experience, which value finds the best balance between the two things (make sure the update is downloaded, but do not annoy the user by taking too long to run)? – fedorqui Apr 10 '19 at 10:32
  • 3
    I haven't experimented with it much actually. We just removed it to make sure that people stay on the latest version to the largest extent possible. If it's not that important to you, I would probably set it to somewhere around 15s to make sure that it makes an "honest attempt" at fetching the latest version, no matter how bad the connection might be. – Jacob Sievers Apr 10 '19 at 11:16
  • I didn't see this in the list of OTA limitations in the Expo documentation , but , just in case, from your experience, were you able to push updates.fallbackToCacheTimeout changes OTA ? (without submitting a new binary, obviously) – Jar Aug 29 '19 at 15:57
  • @Jared You should be able to change anything not listed in limitations (https://docs.expo.io/versions/v34.0.0/workflow/publishing/#limitations). Of course the update to `updates.fallbackToCacheTimeout` won't apply until after a user has successfully performed an OTA update (with the old settings). – Jacob Sievers Sep 12 '19 at 11:17
  • @Jared Yes, you can submit fallbackToCacheTimeout via OTA. the flow would be 1- change fallbackToCacheTimeout. 2-publish it. 3- restart the app as usual. 4- Now published all new changes 5- Just open the app to see changes – Furquan Aug 05 '20 at 09:27
  • This is seriously bad wording. I thought it supposed to run the app while downloading the updates and than restart. – Ali Mert Çakar Jun 17 '21 at 09:53
  • I have been having this issue for the last couple of months and I finally found the answer Thanks @JacobSievers – Faraz Irfan Apr 29 '23 at 18:57