SDK Version: 44+
Platforms(Android/iOS/web/all): all
We are trying to set a lean and clearly understandable policy for the Expo OTA in the EAS. We would like to set the procedure as “if XYZ happens, customers should go through the App Store process and for all other cases we will push the changes via OTA”.
According to the related documentationexpo.runtimeVersion configuration within the app.json indicates which bundles are going to be downloaded by the end user app installations via OTA updates.
In this case should we update the expo.runtimeVersion anytime we modify the package.json or when we modify a new library that touches native (iOS or android) API or both?
As far as I understood; we did not have such an issue in expo build because it implicitly dictates a new version should go through the app stores when the expo SDK version is changed, is this comment true? (If it is true, does it mean expo build did not require any new app store release when we changed the package.json for other libraries?)
What happens if we set runtime: {"policy": "nativeVersion"} as stated here? Does it decide automatically the expo.runtimeVersion value? If so, what is the rule to set the expo.runtimeVersion?
you have to change runtime version whenever native library changes api that used to communicate between js and native code.
For expo packages this api is compatible within sdk, so if you use expo install you can update libraries without bumping runtime version.
For pure javascript libraries you don’t need to change runtimeVersion.
For non expo react-native packages you need to consult their documentation
I think it’s a good practice to change runtime version on any change in packages that have native code, even if technically it’s not necessary
expo build ignored native code from node_modules, your app was created from prebuild archives that included all expo modules and some third party libraries. Values you had in package.json affected only js and expo install made sure that you have correct version of js versions
Thanks a lot for the comprehensive answer @wkozyra95. More or less everything is pretty clear.
One point:
I think it’s a good practice to change runtime version on any change in packages that have native code, even if technically it’s not necessary
For this part, in my opinion we need to avoid updating runtime version as much as possible. Because, as far as I understood, runtime version upgrade will push end users to go to the stores and update their applications. This means we miss OTA opportunities.
Actually that understanding at our side is the reason of this topic.
yes, but note that it’s very easy to introduce some breaking changes by mistake, so you are relying on authors of the libraries to make sure that they are properly testing that. If you plan use OTA as much as possible you should make sure to test it on versions of native runtime you uploaded to store.
Also note that for app store it’s against their terms of service to circumvent the review process, so OTA updates should only be used for small bugfixes that do not change app in any significant way.
For expo packages this api is compatible within sdk, so if you use expo install you can update libraries without bumping runtime version.
to clarify that part, expo install is safe if you are updating expo package, not if you are adding new one
Yes, that is exactly correct. Our intention is, to avoid forcing end users to update their apps, for our library upgrades. (We want to keep the library version levels as latest as possible. And in the JS universe this means very frequent app updates via store.)
To reduce that, OTA is the method we want to utilise. (Along with, as you stated, bug fixes of course.)
Our intention is, inline with Expo SDK lifecycle, to push the customers to app updates once in every quarter, not more than that.
I think of this as if I have my own SDK that is a combination of the Expo modules and whatever native third party modules I have installed along with the options used for any Config Plugins. If I change this “SDK” by installing/upgrading versions of these native dependencies or maybe using different Config Plugin options etc., then I will need to publish a new build to the stores.
In addition to that, like for expo build, making certain changes to app.json would also require a new build.