如何更新CapacitorJS应用程序而无需重复提交商店审查

很高兴您问到了。

我不是在提供法律建议。我正在分享团队在安全地发布Capacitor应用程序时广泛使用的实用做法。

重要的是要注意到这一点：

• 原生提交 在新原生行为和主要功能方面仍然需要 __CAPGO_KEEP_0__。
• 实时更新 是针对 JavaScript/web 修复和调整的，仅限于您的现有应用范围内。

两者都可以使用此模型：iOS 和 Android，但您必须将其视为 安全政策流程,而不是漏洞。

苹果和谷歌允许的简单术语

您可以将苹果和谷歌视为共享一个类似的边界：

1. 您可以将 code 交付给嵌入式 web 层（HTML/CSS/JS）而不重新提交。
2. 您不应使用该通道进行重大功能添加，改变应用目的。
3. 您不应通过 JavaScript alone 改变关键安全或分发控制。

苹果的官方指南是围绕 WebKit/JavaScript 更新的，这是此模型的核心。谷歌通常对基于 web 的更新更具限制性，但同样的原则适用：在原生发布中保留原生更改。

什么是Capgo好用的

Capgo适用于：

• 快速修复网页bug
• 安全的UI复制/样式/流程修复
• 在现有页面中进行小规模逻辑修复
• 内部QA快速实验

Capgo不适用于：

• 添加权限或新本机功能
• 通过审查应该通过的核心功能
• 更改签名、加密或包标识行为

推荐发布策略

分两条线思考

Track 1: 原生 Track (应用商店评论)

使用您的正常 Capacitor 发布流程：

• 新插件更新，
• 应用壳或清单更改，
• 权限更新，
• 平台特定功能更改。

这些需要：

bun run build
bunx cap sync
# then App Store / Google Play submission flow

Track 2: JS Track (Capgo)

为了安全的小型运行时更改：

bun run build
bunx @capgo/cli deploy --channel staging
bunx @capgo/cli deploy --channel production

这给您快速迭代而不需要新二进制上传的能力，同时保持二进制本身稳定。

避免“哎呀，这需要原生发布”

在每次 Capgo 发布之前，运行这个快速门控：

1. 是否需要添加新的本机依赖项或权限?
2. 是否改变了应用的宣传能力?
3. 是否改变了认证/安全边界?
4. 是否可以描述为一个不影响 JavaScript 的修复?

如果答案是 (1)-(3) 的是，提交本机发布。 如果只回答是 (4)，请通过 Capgo。

对合规团队来说，这意味着什么

• 您保留了应用审查带宽用于有意义的更改
• 您保留了回滚控制和快速修复
• 您通过在渠道中测试更新来减少生产风险

这与人们在生产环境中使用的大型 Capacitor 程序相同：仅对 JavaScript 修复进行快速更新，仅对真实二进制文件进行本机审查

如果您想深入了解，请将此与基于渠道的严格环境策略配对起来，以便 QA 从未接收到生产错误。这种是 Capgo 本机的方式来保持 staging、beta 和生产环境的清洁