通过 WebView 里的 H5 发功能，像开了个后门：改服务器上的 H5，功能就绕开 App Store 审核上线了。这个「后门」是颗雷。一旦 H5 改变了 App 的行为，或以商店从未审核过的方式桥接原生，苹果和谷歌都可能下架 App，屡犯者甚至会丢掉开发者账号。团队想要的速度，变成了拖垮整个 App 的风险。

两家商店真正在执行的规则

苹果的《App Store 审核指南》2.5.2 说得很直白：App 必须自包含，「不得下载、安装或执行会引入或改变功能与特性的代码」。解释执行的 JavaScript 只有在打包进 App 时才被允许，下载的不行。苹果自己的口径是：React Native 没问题，因为它的 JS 只与一组已审核的原生桥对话；不被允许的是在审核通过后再下载新的原生桥代码。Google Play 的「设备与网络滥用」政策说，App 不得从 Google Play 以外的来源下载可执行代码（dex、JAR、.so）——但给了一条例外：运行在虚拟机/解释器里、间接访问 Android API 的代码（例如 WebView 或浏览器里的 JavaScript）可以，前提是这类代码「不得允许发生可能违反 Google Play 政策的行为」。

H5 热更新的陷阱

陷阱很精确。WebView 里的 H5，是公认唯一能「空中下发 JavaScript」的逃生口——于是团队拿它绕开审核发功能、修 bug、做实验。但这条口子很窄：JS 不得改变 App 的主要用途，不得做成「店中店」，也不得桥接商店从未审核过的原生能力。一旦越过这条线——新的原生桥、不可信的远端脚本、实质改变行为的功能——那个帮你提速的 WebView，此刻把你暴露在苹果的 2.5.2 和谷歌的「设备与网络滥用」之下。更要命的是，裸 H5 热更新没有版本门禁、没有回滚保障，于是一旦推错，在你能修服务器之前，错误对所有人都是线上的。

为什么这是真风险，而非理论

这不是假设。苹果对代码注入的强硬红线，很大程度上正是为了应对 JSPatch——一个曾在中国开发者社区被广泛用来绕过审核下发原生代码变更的框架；苹果封杀了它，并在 2024 年后加强了热修复框架的静态扫描，以至于连一个未使用的 JSPatch SDK 都可能触发拒审。升级阶梯很陡：拒审 → App 从商店下架 → 失去开发者计划账号。谷歌的政策也明确点名：通过额外 JavaScript Interface 加载不可信网页内容的 WebView 是被标记的模式。对于一个托管着成百上千商家小程序的流量 App，某一家商家的 H5 越线，就可能把整个 App——乃至平台的账号——拖下水。

runtime 的解法

宿主自有 runtime 提供的是一条受控的更新通道，而不是一场合规赌博。逻辑和资源依然空中下发、依然快，但每次更新都过平台审核门禁、带灰度发布与即时回滚、并在运行前签名校验。业务方保住了热更新的速度；平台保住了审计链、逃生舱、以及合规的边界。你拿到速度，却不用拿整个 App 去赌。

维度WebView 内 H5 热更新宿主自有 runtime
商店审核绕开，有下架风险在合规边界内的更新门禁
原生桥变更未审核，违反 2.5.2 / 设备与网络滥用经审核、版本化的能力 API
回滚无，全员等修服务器灰度发布 + 即时回滚
爆炸半径整个 App 与账号承压按小程序隔离
审计链无签名、校验、留痕

本系列的贯穿主线是控制权。WebView 让你偷偷快更、无人看管；runtime 让你快更、且可被追责。对于一个目录里跑的是别人代码的平台，可被追责的速度，才是能熬过商店审核的那一种。

参考来源