Best Practices for App Updates?

#1

After publishing a new update, we want our users to experience the changes as soon as possible. Expo will check for a new version when the app is closed and opened again. However, many users (including myself) rarely close their apps, being content to let them be backgrounded. This means that days or even weeks(?) might pass before they see the bug fix or new feature.

According the docs, there is Expo.Util.reload(), which will force a reload. It looks like it used to be safe to call this method often, as it would only reload when a new version was available (https://github.com/expo/expo/issues/253).

So my question is, How are others handling his situation? It doesn’t look like there is an api for checking if a new version is available.

Any thoughts, ideas, or best practices would be most welcome.

1 Like
#2

I also struggle with that.

I don’t understand why there is no api to simple check if there is a new version. Every code is in place, its just not exposed to js.

Is there any workaround for that?

reloading the app after restart is not enough. Many users don’t close their app at all and hoping for the os to shut down an app is not reliable.

A check for updates after soft restart (from background to foreground) would also be helpful. Also when the app comes back from standby

#3

We’re really struggling with this, as well.

The update listener only checks for updates when the app is first starting, even though it sounds like an always-on thing from the documentation, so, if you only update by publishing to Expo, you’re always at least one app close/ restart cycle away from getting an update.

In the case of Android, you’re always two close/ restarts away from getting the update, because after the first reopen, the update is detected, and on the next open, the update is applied.

Because your JS is bundled whenever you create a new IPA/ APK, it would seem like a new app store update would guarantee that your JS is updated. This seems to be the case with iOS, and, besides, you can disable remote JS downloads for iOS, anyway. But, with Android, in my experience, installing a new APK over the old one does not update the JS.The APK update triggers the first app close, and thus the update is downloaded when the app is opened again, but it isn’t applied until the next restart after that.

If you listen for the update, there is the option to call Util.reload(), but that appears to be broken for apps that secure images behind session cookies (please someone else confirm this is an issue, I’m going crazy here).

In conclusion, it appears that even publishing a new APK cannot guarantee your users will get the latest JS soon after the Play Store update. This is a big deal when you think of a critical bug fix or rolling out a new feature - if a user sees from iOS / Android that your app was updated, but they go into the app and don’t see any of the changes, that’s not good. My leadership has told me that’s unacceptable.


The one way I know to virtually guarantee your user gets the update in a timely manner - or at least definitely gets the update when the Play Store is updated - is to make it impossible for your new version to use JS from the old version. So,

a) always do updates via the App Store / Play Store (or at least important updates), and
b) upgrade Expo to a new version in your new IPA/ APK
OR change your slug***
OR use a new release channel

I’d be so happy if someone from Expo could validate my experiences here or tell me what is either something I’ve done wrong or is maybe a one-off experience. I’d be happy to write a small book on it if I had a fact-checker. This stuff is amazing, OTA JS bundle updates are great for a certain audience, but it is currently really hard to understand precisely what is going on, absent of a ton of trial and error (I’ve published 23 updates this week alone just trying to figure out what’s going on).

*** I’ve tried this at least for Android - Expo’s build process doesn’t mind that you change the slug. Just remember to download your certs/ keystore so you can provide them when you build with the new slug- Expo saves those based on slug.

#4

So scratch the “changing your slug” option if you use push notifications - I just found out that updating with a new slug causes duplicated push notifications. I really hope that’s not the case with release channels.

#5

Scratch the “upgrade your Expo version” option - I just confirmed that it still loads the old JS after you update your Android APK from one that targets Expo 22 to one that targets Expo 24.

Build channels is up next…

#6

And I just confirmed that release channels don’t work for this, either. So, there’s no way to ensure your Android JS is updated when your APK is updated.

#7

For anyone interested, I’m posting the latest on the issue I’m experiencing with updates at https://github.com/expo/expo/issues/1122.

APK updates actually do appear to take effect on first launch on Android 7.0 devices, but not on 6.0 and earlier.