In the OTA section of the EAS Build Docs, it states:
Your native runtime may change on each build, depending on whether you modify the code in a way that changes the API contract with JavaScript.
It links to documentation for the bare workflow that explains react-native-unimodules and how to configure expo-updates using runtime versions / release channels.
Because I’ve only used the managed workflow, and have now switched to EAS Builds, working out changes in the “API contract with JavaScript” is a bit confusing to me.
I am wondering if there are any rules of thumb as to when I should build a new binary versus publishing an OTA update.
For example:
If I add a new npm package, should I always build a new binary and use a new release channel?
Is there a way to know if a package I’ve added will use a new native module?
The native runtime is the name for your built app binary, it includes native code like the Camera API. @notbrent did an excellent job describing this in these two blog posts.
As a rule of thumb, I think we can say this:
Not every library includes native code, some are created using JavaScript only. These libraries don’t “change” the native runtime and are fine to push in an update.
All libraries containing native code, e.g. have an android and/or ios folder, “change” the native runtime. These changes require you to rebuild your app.
Changes in the configuration of your app, like icons or notification icons, require a full rebuild as well. Configuration like this is reflected in native code when building your app.
Sometimes, the folder structure is more complex. I think the best thing to do there would be to see if the setup guide (e.g. in the readme) contains edits in native code or native configuration. That should help some of the edge cases
Or another approach I have taken in the past is just rebuild when the lockfile’s hash changed. That might include unnecessary builds when the changed libraries are JS only. But it does help getting confidence you are not running into issues there