一文详解 APP 版本更新管理需求设计
APP 在发布之后，会根据产品的发展和用户的需求不断更新迭代。本文作者就 APP 版本在更新管理中必备的需求设计进行了分析，与你分享，希望对你有帮助。
一、app 的更新流程
app 都会不断迭代更新，在应用市场上架的 app，常见的更新， iPhone 是跳转到 App store 更新完成后打开即完成，Android 通常是检测到新版本，下载完成，继续安装再次启动即可。
(相关资料图)
app 更新的流程图大致如下：
一般 app 更新这个环节是技术主导去完成，产品这边主要是提更新策略，提供上架审核的资料等。这种也是 app 需要上架的情况。
还有另一种情况，app 不需要在应用市场上架。app 只给部分人员，通常是公司内部少部分人使用，只需把最新的安装包发给相关人员，完成安装即可。
本文叙述的内容是 app 更新策略的需求设计，指通过用户端和服务端联合实现用户端多版本检测更新。
二、名词概念说明
app 更新策略有两种，分为强制更新和非强制更新：
强制更新：app 更新到最新版本才可使用，在应用内常见的表现是弹窗提示强制升级才能正常使用，不做升级会直接退出应用。
非强制更新：用户不更新到最新版本的也能正常使用。
app 更新的提示也分为两种：提示和不提示，根据提示的频次分为强提示和弱提示。更新策略 + 更新提示组合就组成了应用常见的 4 种升级方式：强制升级、强提示升级、弱提示升级、不提示升级。
不同升级策略的使用场景：
根据不同的升级场景选择不同的升级策略，以下为 4 种策略的使用场景和界面示意：
强制升级：一般是 app 出现重大 bug 严重影响用户使用，或者后续更新的功能未能兼容到所有版本，低版本的需要升级到高版本才能正常使用新功能。在启动 app 时不做升级只能退出应用，如下图所示：
我们的 app 上新时会往起兼容两个版本，通过埋点数据也能看到在 app 上了新版本后一周内，苹果用户基本都会更到最新，安卓用户在 40-50% 左右，所以我们的 app 很少强制更新，只会对版本很低的使用这个策略。
强提示升级：强提示升级是在启动 app 时提示用户自主去做升级，用户可选择升级也可选择下次再升级，不升级到最新版本不影响 app 的使用。用户选择下次再升级后，可根据设置的升级提示频次提醒用户，如：启动 app 提示、一天提示一次、三天提示一次、七天提示一次等等。
强提示升级通常用于指引用户完成升级后使用某些功能，我们平台曾跟建行合作过一次营销活动，在平台开建行户后即可获取一定的奖励金额，完成这次活动是需要在我们平台接入开通银行卡 sdk，接入 sdk 是无法兼容旧版本的，且不更新到最新版本也不影响正常使用我们的 app，但为了达成此次活动目标，制定的策略是用户在参加活动时会判断用户当前的版本号，若不是最新版本会提示用户更新到最新版才能参与，提示的频次是：每次都会提示，不升级到最新版不能参与。
弱提示升级：弱提示跟强提示的区别在于提示的频次，在 app 的内可用弹窗或者是 tooltip 等更弱的提示，若用户选择不立即更新，之后就不再提示用户升级。
不提示升级：不提示升级就是 app 在发布新版后在 app 端不使用弹窗或 tooltip 提示，通常是在 app 端版本更新页面，通过红点等方式引导用户进入目标页面做版本检测和更新。
三、管理后台设计
管理后台主要是维护 app 更新策略，在梳理清楚 app 端升级场景后可着手于管理后台的设计，app 端偏向于场景梳理，管理后台着重于逻辑。在管理后台的设计上规则还是先正后异，也即先按照正常流程设计，再补充异常流程，最后切换视角检查。
正常流程：各平台 app 的升级策略，延展开即为 iOS 或安卓端 app 的那个版本在何时按照何种升级策略进行升级，升级的内容是什么。根据正常流程即可梳理出创建版本升级所需的字段内容，如下图所示：
异常流程：在需求设计中，异常场景的考虑十分关键，在开发和测试环节，技术和测试同学也不会放过任何一个异常的。对于异常流程的思考其实就是对正常流程的找茬，对正向流程的每一个节点加上变量后看出现的情况是否已有相应的解决方案，
例如：app 是根据版本号进行判断进行更新，当前有 1.0、1.5、2.0、2.5、3.0 个版本，制定的策略是：2.5 版本强更，如此设定后，2.5 以下的版本应为强更，2.5 上的版本可设置强更或非强更，也即是 app 的更新策略应为多条。
异常情况整理如下：
第一种情况：更新版本号为强更时，低于更新版本号的版本也要为强更，高过更新版本号的版本可强更或不强更。
第二种：更新版本号为非强更时，低于更新版本号的版本可以非强更或强更，高于更新版本号也可如此。
第三种：更新版本号为非强更时，若低于更新版本中有过强更的策略，则低于强更的版本应更新到强更版本。
四、总结
app 升级管理很常见且不复杂的需求，在做设计之前也参考了一些别人的设计，但看的一知半解的，把本次的需求设计整理下来一是新写作方向的尝试，二是想把需求设计用更简单的方式表达出来。
本文由 @努力努力再努力的 PM 原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自 Unsplash，基于 CC0 协议。
