EAS OTA Updates - Knowing When to Build a New Binary

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?

Hi @peroh!

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.

Hope this helps!

Thanks very much @bycedric !

This answers the part I was most confused about:

All libraries containing native code, e.g. have an android and/or ios folder

I didn’t realise I could just check the npm package for these folders to work out if it had native code.

Thanks for linking Brent’s posts and for the rules of thumb. Much appreciated!

1 Like

No problem, happy to help!

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 :grinning_face_with_smiling_eyes:

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 :grinning_face_with_smiling_eyes:

Ahhk cool - good to know.

Yep I think that sounds like the safest approach :ok_hand: