App 版本管理：做法和版本对比方法

App 版本管理是给移动 App 的发布编号和跟踪：一个给用户看的版本号，加一个一直递增的构建号。本文把语义化版本套用到 App 上，列出九个做法，说明版本之间该对比哪些指标，并用一次分阶段发布演示：崩溃退步在只覆盖 10% 用户时就被发现了。

什么是 App 版本管理？

App 版本管理（App Versioning）是给移动 App 的每次发布编号、跟踪的一套规则。每个版本都有两个标识：用户在商店和设置里看到的版本号（比如 4.2.1），以及每次上传都必须递增的内部构建号。iOS 上是 CFBundleShortVersionString 和 CFBundleVersion；Android 上是 versionName 和 versionCode。

好的版本管理让团队的发布有章可循，让用户和客服知道某人用的是哪个构建，也让统计能按版本对比行为、崩溃和留存。

App 的语义化版本

大多数团队会改用语义化版本（SemVer）：主版本.次版本.修订号。

SemVer 原本是给软件库写的，「不兼容」指 API 不兼容。对 App 来说，团队通常把主版本当作市场或改版的里程碑，而不是严格的规则。也有团队用日历版本（比如 2026.11.1），一眼就能看出发布日期。

App 版本管理的做法

1. 版本号和构建号分开。 构建号一直递增；版本号按你的规则走。
2. 同样的功能集，iOS 和 Android 用同一个版本号。 即使构建号不同，客服和对比也更简单。
3. 在持续集成里自动生成构建号。 用流水线编号或时间戳，一直不会撞号。
4. 每次发布都在代码库打标签。 有 v4.3.1 这样的标签，很容易找到崩溃对应的代码。
5. 每个版本写更新说明。 商店里写给用户，内部写给团队。
6. 每个统计事件和崩溃都带上版本号。 没有它，就没法对比版本。
7. 分阶段发布。 先发给一部分用户，看无崩溃用户占比没问题再扩大。
8. 规定最低支持版本。 旧版本和服务端改动不兼容时，强制或提示更新，并跟踪还有多少人停留在旧版本。
9. 紧急修复用修订号发布。 让大家看得出这次只修了 bug，没加新功能。

怎样对比 App 版本

每个新版本发布后的头几天、头几周，和上一个版本对比：

要同类比同类：早早更新的用户往往更活跃，所以除了全部用户，也要看各版本上新获取的用户。

每次上传商店，构建号都必须递增。

计算示例：发现一次退步

某外卖 App（示例数据）把 7.4.0 发给 10% 的 Android 用户：

无崩溃用户占比掉了 1.3 个百分点；错误分组显示，改版后的地址选择器在 Android 11 上出现了新崩溃。发布停在 10%，两天后 7.4.1 修复了崩溃，再继续发布。因为只有 10% 的用户拿到了 7.4.0，约 90% 可能发生的崩溃被避免了。

常见错误

• 重复使用构建号。 商店会拒绝，崩溃报告也会混淆。
• 同一次发布在 iOS 和 Android 上版本号不同。 客服和统计都会乱。
• 统计事件不带版本号。 分不清变化是不是来自某次发布。
• 首日就全量发布。 一次退步会影响所有人。
• 从不淘汰旧版本。 安全和接口的改动迟早会要求这样做。

在 TapCub 里跟踪 App 版本

• 版本报表： 应用统计 › 用户分析 › 版本分布 列出每个版本的平台、占活跃用户的比例、崩溃数和首次出现日期，并用堆叠图显示主要版本。点击某一行，当前报表就会按这个版本筛选。见跟踪 App 版本。
• 稳定性： 无崩溃用户、崩溃、ANR、界面卡顿和冷启动；错误分组可以标为已解决。
• 漏斗和留存： 按 App 版本筛选，逐个版本对比转化和留存。

相关阅读：无崩溃率、提升 App 性能、App 改版。

常见问题

版本号和构建号有什么区别？ 版本号（比如 4.3.1）是用户看到的；构建号是内部计数，每次上传到商店都必须递增。

iOS 和 Android 要用同一个版本号吗？ 功能集相同的话，要。构建号可以不同。

什么时候升主版本？ 发布是一次大改版，或者带来不兼容的改动时。对 App 来说，这常常是产品或市场的决定。

旧版本要支持多久？ 直到使用旧版本的人很少、并且它们不再妨碍服务端或安全改动为止；规定最低支持版本，并提示用户更新。

参考资料

• Preston-Werner, T.：语义化版本 2.0.0
• Android Developers：为应用设置版本
• Apple Developer：CFBundleShortVersionString