这是《App产品设计指南》系列文章的第9篇内容，更多精彩可以点击下方链接查看。
版本更新类型
版本更新是App经常出现的组件，当产品有新功能或者修复问题都需要更新新的版本。通过此组件，提醒用户升级。版本更新主要有以下几种方式。
建议更新
当平台推出的的功能不是很重要或者不影响老版本的时候，一般都会使用建议更新。用户可以自主选择是否升级，决定权掌握在用户手中。
Android客户端的建议更新都是从平台服务器上进行更新。如果为了区分各大应用市场，比如应用宝，百度等等，可以针对不同的市场提交渠道安装包。用户下载安装后，平台能及时统计到数据。
客户端可以在网络好的时候后台下载更新的安装包，然后在下一次启动App时提示用户安装新版本，这种做法也比较常见。
建议更新可以出现在应用首页或者是使用特定功能时提醒用户升级。
苹果审核时不允许App内有任何提示版本更新的内容, 否则拒绝上架，必须在App Store进行更新。但我们也可以在App中增加更新引导，点击跳转到App Store进行更新。但在苹果送审期间我们需要关闭版本更新提示，不然被审核的工作人员发现就会被驳回导致不能上架。（苹果送审期间可以通过一些手段来躲避审查，比如说屏蔽掉某些页面，让工作人员看到特定页面等等）
强制更新
当政策法规发生变化，或者旧版本再使用会出问题，平台就会使用强制更新。用户如果不接受就不能再继续使用服务。除非是万不得已，否则不建议使用强制更新。
由于iOS的特殊性，自然也就不存在强制更新这种方式。
热更新
热更新是指用户通下载安装APP之后，打开App时遇到的即时更新，通过这种形式能绕开应用市场的审核机制。这种做法在各大手游等App上比较常见。
2017年6月，AppStore审核团队针对AppStore中“热更新”的App开发者发送邮件，要求移除所有相关的代码、框架或SDK，并重新提交审核，否则就会在AppStore中下架该软件。 但需要说明的是苹果是禁止特定种类的热更新，而不是所有的热更新。苹果禁止的是具有修改APP原生代码能力的热更新。
版本更新原理
介绍完版本更新的几种方式之后，我们来说一说版本更新背后的原理。
核心原理
在App启动的时候使用本地的版本号与服务端版本号进行版本。如果两者相等，则不需要有提示；如果小于服务端版本号，则显示对于弹窗，具体的升级类型需要服务端返回。至于本地版本号大于服务端版本号的情况基本不会出现，一般会出现于内部测试版本这种场景。
Android客户端是与软件服务商进行对比，iOS客户端则需要与苹果官方的版本信息进行对比。
其他注意事项
1.针对Android版本更新的设置主要包括应版本号、是否开启版本更新、应用版本、应用大小、升级方式、更新日志、安装包下载地址。
2.针对iOS版本更新的设置主要包括应用版本号、是否开启版本更新、是否开启iOS审核模式。
3.可以设置哪些客户端版本需要更新，比如版本号1-20的版本建议升级到最新稳定版本30。
4.在第3种情况的基础上可以进一步拓展，设置特定版本的升级类型，比如指定版本号28的用户升级到测试版31，版本号29的用户升级到最新稳定版本30。上面两种情况的处理逻辑需要放在服务端进行处理。
5.小版本号尽量做到兼容，大版本号更新可以考虑强制升级。
6.尽可能地向下兼容，具体兼容几个版本需要根据公司实力和业务类型决定。
我们在设计App的MVP版本时，一定要设计好版本更新，避免出现“孤魂野鬼”的情况。否则即便你推出了新版本，用户还是可能不买账。
在写作过程中，如果有意见或者想法，欢迎有兴趣的读者添加我的微信，加入微信群一起交流探索，共同进步。
