在产品工作中，经常要对产品APP进行迭代升级。本文作者根据自己的工作经验，对APP版本升级管理这个问题展开了深入的思考，希望对你有帮助。

移动端功能开发测试完成后，需要引导用户安装新版本，针对用户量级较大的APP这个过程中会分为两个阶段：灰度阶段和正式阶段。

灰度阶段是面向部分用户投放应用，目的是验证应用包的可用性及兼容性问题。正式阶段是面向全量用户投放正式的应用，目的是引导用户升级到新的版本。

实施方式：

灰度阶段有两种方式：APP灰度——全量功能APP分发给部分用户试用。功能灰度——部分功能由后台控制开关供部分用户使用正式阶段（全量开放）：经检验没有问题的APP上传到各应用市场，同时引导老用户进行版本升级

本文仅针对正式阶段，面向全量用户进行新版本升级引导的APP版本升级管理进行展开讨论。

版本升级流程：

版本升级总共分为两步：安装包发布到官网，引导用户升级到新版本。

流程图如下：APP官网投放、iOS需要上传appstore审核，安卓可依据需求投放不同应用市场。

特别说明：因为App Store存在审核时间长的特性（3-14天不等），如果需要两端同步发布一般是需要先将iOS端进行提审，再讲安卓提审（安卓应用市场审核周期为一天左右），等到应用包已经上架应用商店后，接下来就是引导已经安装APP的老用户进行升级到新版本各应用商店有自己的应用升级方式。

但是升级过程会很被动（比如用户关闭自动升级，新版本存在功能不兼容导致用户不能使用），所以需要我们自己开发管理后台去控制各版本之间的升级方式

运营配置升级流程：

引导用户升级需要在后台做两步：配置需要升级的安装包信息，设置升级方案。

第一步：填写安装包信息

不同渠道的安装包需要填写的安装包信息不同，iOS之所以分为三种发布类型是可以理解为两个用途：appstore用于正式安装包配置，企业分发/testflight为内部测试升级使用。

testflight是苹果提供给开发者专用的测试方式，用户需要测试之前需要安装苹果提供的一个testflight工具，然后会收到开发者的测试升级邀请，或者通过开发者开放的一个公开链接去下载测试包。

testflight这种方式一是测试人数有上限（9999人），二是需要额外安装工具。

内部测试的话，也可以通过企业证书打包的方式，企业证书是面向企业内部员工使用的APP的开发者证书。开发者只需要将应用打包，生成应用下载二维码，这样用户就可以直接扫码安装。

两者可以依据现实情况考虑，不是必要选项。

第二步：设置升级方案

这里面有两种主流升级方式：依据最新版本升级方式引导升级，依据用户当前所用版本升级方式引导用户升级。

依据最新版本升级方式引导用户升级：不管用户当前所用版本，所有版本都是依据最新版的升级方式来升级的。

优点：引导性强，可以快速引导全量用户升级到最新的版本。

缺点：影响范围广，比如本次新版功能只针对上个版本用户做了bug修复，需要强制升级，但是其他版本用户虽然没受到影响也需要跟着一起强制升级。

依据用户当前使用版本的升级方式引导用户升级：新版发布时，为每个历史版本配置该版本的升级模式，比如新发布2.0.0版本，为1.2.0版本配置提示升级，为1.1.0版本配置不提示升级，为1.0.0版本配置强制升级。

优点：针对性强，可以兼容历史版本，用户影响范围小。

缺点：维护成本高，随着版本数量增多，会存在需要维护的历史版本多的情况所以升级方案参考了上面的两种升级方式，采用第一种依据最新版本升级方式，但又补充了最小兼容版本，尽可能在用户体验及维护成本中平衡，先看下用户端的升级判断逻辑。

提醒用户升级方式有四种：

升级策略的触发条件除了最新版本配置的升级方法外，考虑到了历史版本兼容性问题，增加了最小兼容版本的这个字段，就能满足在固定版本以前无法正常使用，需要强制升级的逻辑场景。

最小兼容版本就是，最新版本升级逻辑仅支持的最小版本号，小于该版本的历史版本均采用强制升级，保障用户的基本使用体验，其余版本则遵循最新版配置的升级逻辑。

版本管理列表：

新建版本：

客户端升级弹窗：

总结：

做好一个移动端产品，除了需要研发新的功能满足用户的需求，还需要关注版本的更新迭代节奏。如何用更好的方式引导用户升级，以及建立良性的迭代循环和版本兼容管理，都是值得思考的，如果更多的好的想法欢迎一起交流沟通~

本文由 @胡小圈儿 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议