随着公司业务的不断演化，或者是后台接口的重大更新，某些旧版本App已经不能正常为用户提供服务。
这种情况下，应该强制用户更新 App。
否则，继续使用有问题的旧版 App 将导致错误数据的产生，频繁的错误和闪退也会引发用户更加强烈的不满。
值得注意的是，需要旧版本进行强制更新，首先必须确保旧版本已经预留了强制更新的功能。
个人建议最好在第一个版本就预留强制更新功能，而且非常建议 App 向后台发送的的每个请求，都附带上 App 版本号、设备的系统版本号。让后台知道版本信息，有利于它灵活的限制 App 的请求（比如，需要限制使用某个功能必须更新到最新版）；另外对于排除错误也是相当有利。
配合后台接口
规定向后台发送的每个网络请求都传递 App 的内部版本号，后台根据app版本号判断是否需要强制更新，如果需强制更新，则向此次请求返回约定好的错误信息，App 端接收到该错误信息，用弹窗提示用户更新。
这样能确保在提示用户更新的前提下，拦截每次旧版 App 发送请求，不至于后台产生错误信息。
好处是 检测更新及时，有利于它灵活的限制App的请求。
坏处是 需要后台配合，对于原本只有网页版的旧项目，后台还需要为旧接口补充判断版本号的逻辑。
利用itunes版本号
一般使用的是 GNU 风格的版本号：主版本号.子版本号.[修正版本号]
我们为 app 设置的版本号可以通过这条URL获取到：https://itunes.apple.com/lookup?id=<Apple ID>
当你在 itunesconnect 创建应用时，就有一个固定的 Apple ID 与该应用对应。在 itunesconnect 上可查看：
该URL返回的 json 数据，内有 version 字段，对应的值就是该 App 在 App Store 上的最新版本号。
所以，有这么一个主意，通过对比主版本号来标识是否需要进行强制更新。app通过对比返回数据的主版本号和当前app的主版本号，当前者比后者大时，弹窗提示更新，并且弹窗不可关闭，只提供一个跳转 App Store 的按钮。
比如，App Store 上现有版本是2.0.0，现在发布一个新版本，需要旧版本强制提示更新，那么新版本号该改为3.0.0。当新版本审核通过后，从 iTunes 获取到的版本号将变为3.0.0。旧版本 app 的主版本号低于 App Store 上的主版本号，就会判断到需要强制提示更新。
使用此机制的好处是，不依赖后台。
坏处是 相比公司自己国内的服务器，访问Apple服务器的速度会慢一些。