移动产品基础模块设计规范之应用更新!
众所周知,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 端要慎用,慎之又慎。配置错误会导致比较严重的问题。
写在最后
如果你的应用有分身版,在提示更新中还要增加针对分身的选项。不然,会出现分身版会成为主版的引流平台。
想获得更多的用户,请点击链接:ASO优化服务介绍
本文作者@郑几块 由(APP顶尖推广)整理发布,转载请注明作者信息及出处!
扫一扫 微信咨询
商务合作 联系我们