Do over-the-air JavaScript updates to a React Native app break App Store or Google Play rules?

## Why the question comes up A React Native app is a native binary plus a **JavaScript bundle** that the binary loads at startup. Because the bundle is just a file, it can be replaced after installation: an **over-the-air (OTA) update** downloads a new bundle and assets and runs them on the next launch, with no store review. Interviewers ask whether that is allowed because both stores have rules about apps changing themselves after review. ## What Apple allows Apple's rules pull in two directions: - The **App Review Guidelines** require apps to be self-contained and forbid downloading or executing code that introduces or changes features or functionality. - The **Apple Developer Program License Agreement** carves out **interpreted code**: it may be downloaded, but only if it 1. does not change the app's **primary purpose** by adding features inconsistent with what was submitted and advertised, 2. does not create a **store or storefront** for other code or apps, and 3. does not bypass **signing, the sandbox or other security** features of the OS. A React Native JS bundle is interpreted code in this sense (Hermes executes it), so an OTA update is allowed when it stays inside those three limits. ## What Google Play allows Google Play's Device and Network Abuse policy says an app may not **modify, replace or update itself** by any method other than Google Play's update mechanism, and may not download **executable code** such as dex, JAR or `.so` files from outside Play. It then excepts code that runs in a **virtual machine or interpreter** where either provides indirect access to Android APIs. A React Native bundle runs in the JS engine and reaches Android only through native modules already compiled into the binary, which is why OTA updates of the bundle are generally read as falling under that exception. ## What this means in practice | Change delivered over the air | Acceptable? | Why | |---|---|---| | Fix a crash in an existing screen | Yes | Same purpose, interpreted code | | Adjust copy, layout or styling | Yes | Within reviewed functionality | | Enable a feature hidden from the reviewer | No | Circumvents review of the app's purpose | | Turn the app into a different kind of app | No | Changes the primary purpose | | Download and run third-party mini-apps | No | Creates a storefront for other code | | Add a native module or permission | Impossible | Native code and entitlements live in the signed binary | ## The technical boundary matches the policy boundary An OTA update can only replace what the binary loads at runtime: the JS bundle and assets. It cannot add or change: - **Native code**, including a new native module, because that is compiled and signed into the binary. - **Permissions and entitlements**, which are declared in `AndroidManifest.xml`, `Info.plist` and the provisioning profile. - **The app's identity and version** as the store knows them. A bundle that calls a native module the installed binary does not contain simply fails. Keeping OTA bundles compatible with the binaries in the field is a separate topic. ## The scenario: a bank app's redesigned home screen A bank app plans a redesigned home screen. The team asks whether they can ship it over the air to skip review. The redesign uses only existing native modules and stays within the app's banking purpose, so the rules allow it. The better answer is to ship the first version through the stores anyway, where it gets a staged rollout, and keep OTA for fixes to it. A new biometric login using a new native module could never go over the air. ## Answering well in an interview 1. State that both stores permit downloaded interpreted code within limits. 2. Name Apple's three limits and Play's interpreter exception. 3. Give examples on each side of the line. 4. Point out that native changes need a binary for technical reasons, not only policy. 5. Add that OTA content still has to follow the store's content rules.