你问到了。
我不是在给法律建议，我是在分享团队在安全地发布Capacitor应用程序时广泛使用的实用做法。
关键区别在于：
- 原生提交 仍然需要为新本机行为和主要功能而使用。
- 实时更新 适用于 JavaScript/web 修复和调整，仅限于您的现有应用范围内。
这两个平台都可以使用此模型，但您必须将其视为 安全政策流程而不是漏洞。
苹果和谷歌允许的简单术语
您可以将苹果和谷歌视为共享一个类似的边界：
- 您可以将 code 解释为嵌入式 web层（HTML/CSS/JS）而无需重新提交。
- 您不应使用该渠道进行重大功能添加，改变应用目的。
- 您不应仅通过 JS 来更改关键安全或分发控制。
苹果的官方指南是围绕 WebKit/JavaScript 更新的核心，这个模型。谷歌通常对基于 web 的更新更具限制性，但同样的原则适用：在本机发布中保留本机更改。
什么是Capgo?
Capgo适用于:
- 修复web bug
- 安全的UI复制/样式/流程修复
- 在现有页面中进行逻辑修正
- 内部QA快速实验
Capgo不适用于:
- 添加权限或新native能力
- 通过审核的核心能力
- 更改签名、加密或包身份行为
推荐发布策略
思考两个轨道:
Track 1: 原生 Track (App Store 审核)
使用您的正常 Capacitor 发布流程:
- 新插件更新
- 应用壳或清单更改
- 权限更新
- 平台特定功能更改
这些需要:
bun run build
bunx cap sync
# then App Store / Google Play submission flowTrack 2: JS Track (Capgo)
对于安全的小型运行时更改:
bun run build
bunx @capgo/cli deploy --channel staging
bunx @capgo/cli deploy --channel production这让您快速迭代而不需要新二进制上传，同时保持二进制本身稳定。
如何避免“噢，这需要原生发布”
在每次 Capgo 发布之前，运行这个快速门控:
- 是否需要添加新的本机依赖项或权限?
- 是否改变了应用的宣传能力?
- 是否改变了认证/安全边界?
- 是否可以描述为一个不中断的 JavaScript 修复?
如果 (1)-(3) 的答案是 yes,则提交本机发布。 如果只回答 (4) 是 yes,则通过 Capgo。
这对合规团队意味着什么
- 您保留了应用审查带宽用于有意义的更改。
- 您保留了回滚控制和快速修复。
- 您通过在渠道中测试更新来减少生产风险。
这与生产中使用的大型 Capacitor 程序相同：仅对 JavaScript-only 修复进行快速更新，仅对真实二进制文件进行本机审查。
如果您想深入了解，请将此与基于渠道的严格环境策略配对，以便 QA 从未接收到生产错误。这种是 Capgo 本机的方法来保持 staging、beta 和生产的清洁。
继续阅读：如何在不重复应用商店审查的情况下更新 Capacitor JavaScript 应用
How to update __CAPGO_KEEP_0__ JS apps without repeat store review How to update Capacitor JS apps without repeat store review 如何在不重复App Store审查的情况下更新__CAPGO_KEEP_0__ JS应用 @capgo/capacitor-in-app-review @capgo/capacitor-in-app-review 有关@capgo/capacitor-in-app-review的实现细节 使用@capgo/capacitor-in-app-review 为@capgo/capacitor-in-app-review提供的原生能力 @capgo/capacitor-native-market 有关@capgo/capacitor-native-market的实现细节 使用@capgo/capacitor-native-market 为@Capacitor/__CAPGO_KEEP_1__-native-market提供的原生能力,并且 为 Capacitor OTA 更新的实用上下文：App Store 审核指南。
