移动产品基础模块设计规范之应用更新

众所周知，Apple 明令禁止在 App Store 上的应用使用检查更新的功能，那么怎么做既能满足提示更新的需要，又能不被 App Store 察觉呢？

目前，友盟等第三方的自动更新已经面临全面下课的境地，有些还在坚持着。友盟曾经提示过，由于 App Store 的申诉，他们可能会在今年  10 月份停掉自动更新的业务（有可能改为付费，或者直接关闭）。

面临这些，我们自己开发来完成提示用户应用更新的功能。

梳理下注意点

• 后台做版本控制，主要是记录当前版本以及历史版本，并能够发布更新日志；
• 后段做版本对比，如果有差别，会返回给客户端，并由客户端提示更新；
• 客户端展示更新，通过后端返回判断是否提示，如何提示。

流程图解析

1. 服务端逻辑

• 客户端发送请求至服务端，请求内容验证 appkey，获得 version_code（Android，iOS）；
• 服务端接收到请求后，验证消息的有效性；
• 若请求有效，则对比请求中的 version_code 是否是最新的。
• 若不是最新的，则说明需要更新；
• 有更新时，根据版本跨度提示强制更新还是非强制更新

2. 客户端逻辑

• 用户打开应用时，客户端请求服务端，获得是否有新版本更新信息；
• 如果没有更新，客户端没有提示；
• 如果服务端返回有更新，客户端会提示对应更新方式（强制、非强制）

3. 一些疑点

• 更新对 iOS 审核的影响，隐藏掉
• 如何获得当前版本号？ 读取本地 code
• 如何对比版本号？本地与服务器返回的 code 进行比较
• 唯一标志 vision_code／vision
• 服务端验证内容主要有："appkey":"xxxxxxxxxx","version_code":1,

  channel

后台设计展示

1. 新建应用更新记录

建应用更新记录，包括系统平台、最新版本、更新版本、更新内容以及更新地址

2. 选择更新版本

历史版本中，更新 iOS 的版本，选择强制更新或者非强制更新。

3. 修改更新版本

修改调整已选中的历史版本更新标识。

4. 确认更新

这里我省去了最新版本、更新内容以及更新地址

客户端展示设计

1. 非强制更新

2. 强制更新。这一点，iOS 端要慎用，慎之又慎。配置错误会导致比较严重的问题。

写在最后

如果你的应用有分身版，在提示更新中还要增加针对分身的选项。不然，会出现分身版会成为主版的引流平台。

 

以上，是近来设计的应用更新相关的规划内容，希望和大家一起讨论，共同进步！也希望能够对大家有帮助！

本文由人人都是产品经理专栏作家 @郑几块 授权发布于人人都是产品经理 。未经许可，禁止转载。