Shipping a feature through a WebView feels like a loophole: change the H5 on your server, and the feature updates without an App Store review. That «loophole» is a landmine. The moment the H5 changes what the app does — or bridges to native in a way the store never reviewed — both Apple and Google can pull the app, and repeat offenders can lose their developer account. The speed teams wanted becomes the risk that takes the whole app down.
The rule both stores actually enforce
Apple's App Store Review Guideline 2.5.2 is blunt: apps must be self-contained and «may not download, install, or execute code which introduces or changes features or functionality.» Interpreted JavaScript is allowed only when it is bundled, not downloaded. Apple's own guidance is that React Native is fine because its JS talks to a fixed set of reviewed native bridges; what is not fine is downloading new native-bridge code after approval. Google Play's Device & Network Abuse policy says an app may not download executable code (dex, JAR, .so) from outside Google Play — with an exception for interpreted code running in a VM/interpreter such as JavaScript in a WebView, but only if that code «must not allow potential violations» of Play policies.
The H5 hot-update trap
The trap is precise. H5 inside a WebView is the one sanctioned escape hatch for over-the-air JavaScript — so teams use it to ship features, fix bugs, and run experiments without review. But the allowance is narrow: the JS must not change the app's primary purpose, must not create a «store within a store,» and must not bridge to native capabilities the store never reviewed. Step outside that line — a new native bridge, an untrusted remote script, a feature that materially changes behavior — and the same WebView that bought you speed now exposes you to Guideline 2.5.2 (Apple) and Device & Network Abuse (Google). Worse, there is no version gate and no rollback safety on a raw H5 hot-update, so a bad push is live for everyone until you fix the server.
Why this is a real, not theoretical, risk
This is not a hypothetical. Apple's hard line on code injection was built largely in response to JSPatch, a framework widely used in the Chinese developer community to push native code changes without review; Apple banned it, and strengthened static scanning of hot-patch frameworks after 2024 — to the point that even an unused JSPatch SDK can trigger rejection. The escalation ladder is steep: rejection, then removal of the app from sale, then loss of the Developer Program account. Google's policy is explicit that a WebView loading untrusted web content through an added JavaScript Interface is a flagged pattern. For a traffic app hosting hundreds of merchant mini-programs, one merchant's H5 that crosses the line can put the entire app — and the platform's account — at risk.
The runtime fix
A host-owned runtime offers a controlled update channel instead of a compliance gamble. Logic and resources still update over the air and fast, but every update passes through a platform review gate, ships with staged rollout and instant rollback, and is signed and verified before it runs. The business keeps the velocity of hot updates; the platform keeps the audit trail, the kill switch, and the store-compliant boundary. You get the speed without betting the app.
| Dimension | H5 hot-update in WebView | Host-owned runtime |
|---|---|---|
| Store review | Bypassed; risk of takedown | Update gate inside a compliant boundary |
| Native-bridge changes | Unreviewed; violates 2.5.2 / Device & Network Abuse | Reviewed, versioned capability API |
| Rollback | None; fix the server for everyone | Staged rollout + instant rollback |
| Blast radius | Whole app and account at risk | Scoped per mini-program |
| Audit trail | None | Signed, verified, logged |
The through-line of this series is control. A WebView lets you update fast and unwatched; a runtime lets you update fast and accountable. For a platform whose catalog is other people's code, accountable speed is the only kind that survives a store review.
Sources
- Apple App Store Review Guidelines — 2.5.2 — apps may not download or execute code that changes features; bundled interpreted code allowed.
- App Store Reject: Guideline 2.5.2 code injection / hot-patching — created largely in response to JSPatch; React Native acceptable, dynamic native-bridge code not.
- Apple DTS / community: JSPatch banned; static scanning strengthened post-2024 — even unused hot-patch SDK can trigger rejection; escalation to account loss.
- Google Play: Device & Network Abuse policy — no executable code from outside Play; JS-in-WebView allowed only if it does not violate Play policies; WebView + untrusted JS Interface flagged.
- Axonbuild: March 2026 reporting tied 2.5.2 enforcement to app-building products — HTML5/JS not embedded may bring Guideline 4.7 into analysis.
