众所周知，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 端要慎用，慎之又慎。配置错误会导致比较严重的问题。
写在最后
如果你的应用有分身版，在提示更新中还要增加针对分身的选项。不然，会出现分身版会成为主版的引流平台。
作者 @郑几块
相关文章
移动产品基础模块设计规范之应用更新
移动产品基础模块设计规范之应用更新（2）
关键字：应用更新, 模块设计, 移动产品