How OTA updates actually work?

I've been working on react-native apps for almost 6 years now and one thing that almost always amazes me is OTA (Over The Air) updates. You never click "Update Now" but you still end up with the latest version of the app with the bugs in previous versions fixed. Ngl, it does feel like magic, but it isn't.

How does traditional app updates work?

Before you understand OTA, you need to understand how app updates work traditionally. Have a look at the following diagram, it should summarize what traditional update look like.

What "Over The Air" updates mean?

OTA, as the name suggests, is the update that does not require person to do any action and yet, it still lands on their phone. As we've seen in the previous section, traditional app updates requires users to download the latest version if they need a bug fixed.

OTA, on the other hand, does not require user to do any manual install. It's over the air.

OTA updates is not limited to mobile apps. It extends to Router's Firmware, Smart TVs, even Tesla - all of them got OTA updates. Imagine driving a tesla and needing to download the latest version everytime you encounter some bugs.. that would be funny LOL.

Now let's look at the interesting part about OTA. We will mainly focus on the OTA updates in react native apps moving forward, but the high level discussion applies to other scenarios that I mentioned just now above with different tech used in their respective scenarios.

Updates that can be considered in OTA

Every modern mobile app has 2 layers - Native Binary and JS Bundle.

Native Binary is the actual compiled app. It has the permission list and native SDKs that the app uses. And most importantly, this is what Apple or Google actually reviews when submitted to AppStore or PlayStore before it is passed to users.

The other layer is JS Bundle that is sitting on top of the native binary layer. It has the application logic, UI screens, business rules (that often changes).

The AppStore and PlayStore review the binary. They never review what that binary decides to fetch and run afterward, as long as the binary does what it says it will do.

And that is where OTA comes in. Most logic is in the JS bundle layer. If there's any UI bug or business logic goes wrong - you simply replace this buggy js bundle over the network (or air) with the latest js bundle with bug fixed.

If that bug required any native changes, let's say a new permission required in app not mentioned in permissions list before, then that change would require changing permissions list --> in turn leading to changing the native binary and hence requiring review from Apple and Google.

How the update actually happens?

Technically, it is a small loop that runs quietly in the background.

1. Check. On launch, the app calls an API and asks: "what's the latest bundle version, and does it match what's on this device?". The server responds with the new bundle version and the diff.
2. Diff. The server won't hand over the whole bundle as doing this multiple times would mean wasted resources - it sends only what has changed, similar to a git diff.
3. Download and verify. The device pulls that diff, checks a signature against it, and confirms nothing got corrupted or tampered with in transit.
4. Apply. The new bundle gets written to a location from where the app reads from next time it fully reloads - not the one currently running in memory, so nothing breaks mid-session.
5. Activate. On the next cold start, the new bundle takes over. Deleting the previous applied version from memory.

Nothing in that loop touches the AppStore. Nothing in it requires the user to do anything except open the app like they always do.

Where does this shows up outside of mobile apps

The same pattern - check, diff, verify, apply - is how a Tesla gets a new dashboard feature overnight, how a smart TV patches a security hole, and how a router fixes a bug without anyone touching it. The stakes are different in different scenarios - a broken app OTA is annoying, but a broken car firmware OTA is not (it is deadly 💀).

Hence, the verification gets much more attention, the closer you get to OTA that controls hardware like in case of Tesla. But the underlying loop doesn't really change - it's always some version of "ask what's current, fetch only the diff, confirm it's untampered, and keep a way back".

Wrapping up

I hope you understood what OTA updates are and how it works. One thing that you should takeway from this - contraints make you think out of the box. If it wasn't for AppStore / PlayStore taking days to review them, then the invention of OTA would not happen. That's what I think.

That's it for today, until next time~