The OTA Illusion: What No One Tells You About Instant Updates At Scale

React Native can run JavaScript from a bundle stored on the device, much like a browser runs a web app. An OTA system downloads a new bundle and points the app to it, but this only updates JavaScript; native changes still require a store release.

Clara’s system tracks builds and artifacts, stores them on S3, and lets the app check for updates and download them. To reduce bandwidth, the team compares build artifacts and ships only changed chunks. For a single large bundle, Hermes base bytecode can make binary diffs smaller.

Clara keeps an update in an evaluating state until health checks pass, then can revert to the previous bundle if the app crashes before it is marked applied. The team also checks chunk checksums before applying an update, which can catch damaged downloads or extraction errors. A custom iOS asset resolver fixed image paths that broke when OTA updates moved the main chunk.

Clara merges about 40 changes to main each day and releases to app stores weekly, so its team manually controls OTA updates rather than using continuous delivery. Updates require an app restart and may be delayed by download or extraction failures. Rollout percentages apply to a particular app version, and multiple store and OTA versions complicate monitoring.

Mruk advises most teams to use an existing OTA solution because building and maintaining one involves many hidden complexities. He recommends checking whether a tool supports rollback, update health checks, and diffs, and understanding exactly what it ships and how it applies updates. Teams should also plan for analytics and monitoring across multiple native and OTA versions.