电子标题应用图标
e-标题
需要广泛公共设备兼容性的公民身份应用。
- Google Play 安装
- 54,900,000
- 商店评分
- 4.8
版本目标
只向每个本地版本发送它可以运行的捆绑包
用户可以根据自己的节奏从商店更新，因此您的应用程序同时有多个本地版本。Capgo 检查每个捆绑包的本地依赖项，根据版本规则阻止更新，并可以将每个本地版本路由到其自己的频道。
14天的无限免费试用。无需信用卡。
原生兼容性文档
--disable-auto-update major, minor, or patch keeps a device from receiving a bundle outside its native version line. These rules compare version numbers only. They do not inspect native code.
原生兼容性文档原生兼容性文档
Set defaultChannel in each native build's Capacitor config, for example v2 or v3. Each line gets its own bundles, and an older line can stay on its last working bundle.
原生兼容性文档如何工作
多个原生版本的团队如何使用Capgo
CI设置允许live update分支和商店分支并行工作。以下每个命令都来自CapgoCLI文档。
-
询问是否需要原生构建
build needed与您的原生包比较channel。它打印yes并退出code 1时需要商店发布，否则打印no时原生live update足够。
build needed参考npx @capgo/cli@latest build needed com.example.app --channel production -
切换到元数据策略
只需这样做一次。从那时起，每个捆绑包都携带一个最小的原生版本，设备低于它会跳过捆绑包。
版本目标文档npx @capgo/cli@latest channel set production com.example.app \ --disable-auto-update metadata -
每日上传实时更新
保持--auto-min-update-version在每次上传时开启。--fail-on-incompatible会停止任务，如果捆绑包需要原生code而channel中没有。
原生兼容性文档npx @capgo/cli@latest bundle upload --channel production \ --auto-min-update-version \ --fail-on-incompatible -
上传新原生版本的包
当新二进制文件发布时，上传其包而不使用 --fail-on-incompatible。 Capgo 提高了阈值，使得旧版本跳过它，并且后续检查将与新原生包进行比较。
原生和 OTA 通道工作流npx @capgo/cli@latest bundle upload --channel production \ --auto-min-update-version
Appflow迁移
从Ionic Appflow迁移?
Appflow将原生版本的实时更新与您匹配。在Capgo中，您可以使用通道和版本规则获得相同的结果：
- 为每个原生线创建一个通道，例如v1和v2。
- 在每个原生构建的Capacitor配置中设置defaultChannel到其通道。
- 将每个捆绑包上传到其原生线的通道。
- 保持--auto-min-update-version在上传时不变，一个需要更新的捆绑包将跳过旧的原生code版本。
原生线通道
// capacitor.config.ts in your 2.x native builds
plugins: {
CapacitorUpdater: {
defaultChannel: 'v2',
},
},
# ship a fix to 2.x users only
npx @capgo/cli@latest bundle upload --channel v2 \
--auto-min-update-version
# 1.x devices stay on their channel's current bundle每个原生线都指向自己的渠道
一个例子布局，包含三个原生版本。
-
原生3.xv3新捆绑包
-
原生 2.xv2仅修复
-
原生 1.xv1无新包
将特性发布到 v3、修复到 v2、并且什么也不发布到 v1。v1 设备将保留其最后一次工作的包。
使用 Capacitor 构建的应用
公开应用必须支持老旧和新版本的原生
公民、健康和预测应用可能支持较旧的 Android 版本和不同设备代。版本目标定位将每个原生构建保持在最新兼容的 Web 包中，而不强制所有人使用一个更新路径。
电子标题应用图标
医疗
连接服务
健康应用，可能需要不同版本的原生壳和网页包。
- Google Play 安装
- 2.78亿
- 应用商店评分
- 4.6
WEATHER
Windy.com - 气象预报
该应用程序的设备能力和地图性能可能会因版本而异。
- Google Play 安装
- 3.29亿
- 应用商店评分
- 4.7
无语气 @ Webincode
开发者, Webincode
“能够将设备 ID 添加到特定组并将更改推送到特定组是救命稻草。”
Nate van Jole
CTO, 私有
“设置起来只需一天时间。基于频道的发布让我在自己的设备上测试之前，确保生产用户不会受到影响.”
Sergiu S
drivolino GmbH
“Capgo Capacitor 更新器插件彻底改变了我们发布更新的方式。过去需要几天的时间，现在只需要几分钟。”
FAQ
版本目标化
关于版本在野外
针对不同时间更新的用户团队
那些永远不会更新本地应用的用户会发生什么?
他们将继续接收与本地版本兼容的包。通过元数据策略，包的最低本地版本高于他们的包会被跳过，他们将保持在当前包中。
是否 --disable-auto-update 大于重大故障?
不。版本规则仅比较版本号， native 在一个小或补丁版本中发布的更改仍会发布。使用 --fail-on-incompatible 或 --auto-min-update-version， 它们检查您的 native 包。
Native Compatibility 文档
CI 如何知道一个更改是否需要一个商店发布?
运行 buildNeeded 或 bundleReleaseType 与通道进行比较。 两者都比较 native 包的元数据。 他们不会看到每个编辑在 ios/、android/ 或 capacitor.config 下，因此在 Git 中也要 gate 这些路径。
在 CI 中选择 OTA 或 native 构建
我们正在从 Ionic Appflow 迁移。 我们可以保留版本匹配的更新吗?
是的。 使用一个通道 per native 行程 defaultChannel， 或元数据策略与 --auto-min-update-version。 Appflow 迁移指南将指导设置。
Appflow 迁移指南
如果一个不兼容的捆绑已经发布了?
将通道指向其历史中的最后兼容捆绑， 或强制内置捆绑， 并发布 native 构建。 notifyAppReady() rolls 回滚一个失败启动的捆绑，但它不是兼容 native code. 的替代品。
回滚文档
