Expo Updates runtimeVersion based on build number
M
Maxime Charruel
This is our workflow and I think this is the same for many organizations:
Setup Expo updates with:
runtimeVersion: {
policy: 'appVersion',
},
- Create an appVersion 1.0.0, build number (10001)
- Generate a TestFlight (channel production), test
- Bug reported on a native library (cannot use eas update), fix the bug, build number (10002)
- Generate a new TestFlight, test
At this point, TestFlight version 1.0.0 (build 10001) is not testable anymore, it crashes on app launch, even if we do not use "eas update" to deploy the fix, which is quite strange imo.
We would like to set runtimeVersion based on build number instead of app version to prevent this problem.
One more problem about the current solution is that if we push the version 1.0.0 (build 10002) in production.
We work on next version 1.0.1 (10101) but, we forget to update appVersion in app.config, we let 1.0.0 and generate a EAS Build on channel production. All of users will have a crash on app launch.
I red the documentation (https://docs.expo.dev/eas-update/runtime-versions/) and you wrote: "If this error does occur, then you can republish a previous known-good update, then ask users to delete the app and reinstall it.".
Asking thousands of user to delete app and reinstall it is not possible.
You also mentioned that you are working on a solution to prevent the crash but in the meantime we also would like to run many same app version on TestFlight and I think, allow setting runtimeVersion with build number can be a solution.
Brent Vatne
hi there! thanks for raising this, i opened this pr to improve docs: https://github.com/expo/expo/pull/37807 - in particular, the app does not just crash when an update is incompatible, rather we recover from the error by rolling back to the previous update (although it is possible it may crash, if so the next launch should rollback in most cases where it was caused by applying the update - see https://docs.expo.dev/eas-update/error-recovery/#explaining-the-error-recovery-flow)
i think in your case, if you are leaning towards being very conservative about update compatibility, you may want to use the fingerprint runtime version policy. i recommend reading the update docs in the pr above! let me know if helps.
M
Maxime Charruel
Hi Brent Vatne, thanks for replying.
Fingerprint sounds good in my case, I will take a look and try it, Thanks.