Is there a way of knowing for sure if an OTA update can be performed? Without it, our release plan would differ quite substantially.
Is it simply a case of looking through the
config to see if any of the pieces have been updated/changed that would stop the OTA sending?
Rule of thumb is that if you change anything in app.json, you have to re-build the app and submit via the store. e.g. updating the SDK version, app icon, etc.
Both helpful, thank you. But also doesn’t quite get me what i need to know…
For example; we recently added Google maps to our application and when released, the OTA code updated correctly, but of course the API keys that were stored in the app.json were not sent OTA as they can’t be.
This lead to users apps crashing as the JS code had been updated just fine, but the keys weren’t available.
So the general rule of thumb is “OK”, but not fool-proof.
In my example, i would have actually expected the app not to have updated OTA as Expo knows full well that it can’t update the nested keys without the user downloading the new Standalone version.
This example also meant that our version control failed as we essentially had no way of know whether or not the user had the correct keys and had to write in some conditions around build numbers, rather than version.
My understanding (which could be wrong) is that the OTA will apply to any app built with the same SDK version. That doesn’t necessarily mean it’s safe for the OTA to apply. Unfortunately I think you really just have to think through of what’s a backwards compatible change or not. Think of it like deploying a new API version to your servers. Sure, you can update the API, but you still may have clients who need the old API to work properly.