一文详解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升级管理很常见且不复杂的需求，在做设计之前也参考了一些别人的设计，但看的一知半解的，把本次的需求设计整理下来一是新写作方向的尝试，二是想把需求设计用更简单的方式表达出来。