早在三个月前，很多iOS开发者肯定都收到了这样一封警告邮件：

看不懂英文没关系，反正邮件大概意思就是：你的APP里包含了可以在审核之后还能更改应用功能或者行为的能力。 现在我们App Store不允许应用再有这样的能力了，你得赶紧去掉相应的功能。

这一动作，宣告着APP Store直接为“热更新”判了死刑，也就是说未来应用更新会完全进入“原生”时代（至少iOS是这样），用户的每次更新都需重新下载完整的新版数据包。原以为只是吓唬吓唬大家，没想到这次WWDC大会过后，苹果玩了真的。

1

“热更新”是什么？

绕开复杂的技术语言不谈，其实“热更新”就是利用软件内的框架协议，允许软件从网络下载并运行调用可执行代码，对软件进行修改。

如果还没懂也没有关系，我们来举个例子。

当我们打开《王者荣耀》时，总会弹出类似下面这样的下载更新页面。

我们打开阴阳师，时常会有这样的画面。

以上这俩其实都是“热更新”的表现形式。但是，如果热更新被禁用，我们可能就不能那么实时的下载更新并游戏了。

像这样。

（这里找了个以前玩阴阳师需要更新时截的图，当时看到快吐血了...800mb呢...）

试想一下，在工作岗位上兢兢业业了一天，j2直播，终于可以在公交地铁上肝一会儿，然后突然发现游戏有更新？还得下载完整（大写）的软件安装包…WTF？

不过幸好，App Store及时出手制止了我为了游戏决定花流量更新的冲动。抱着沮丧的态度，操着几斤崩溃的心，默默关掉了游戏打开了朋友圈...

如此看来，“热更新”好像确实很影响用户对于app的体验，但确实对用户来说是一种保护，那对于开发者呢？

2

iOS开发之踵

说起iOS开发，应该大部分都是从iPhone4开始加入这个生态的。iPhone 3GS时代APP Store 中还并没有那么多APP供应。相比之下大家当时都在规规矩矩手动码着Object-c，码完之后龟速上线…然而这还没完不过不要高兴的太早，因为你还得再等待至少一周以上的时间苹果来为你审核通过...

所以，我们可想而知，不论app在使用过程中出现了什么事故，那都将会是重大的事故。因为对于当时的iOS开发来说，很难做到立即为用户修复bug。要知道从改掉bug到再重新打包上传，还得给苹果大大发一封加急处理的邮件呢...想到邮件的沟通效率…啊，反正这个过程对于重大事故来说还是很漫长。

So，当时大家发布 APP 的时候都非常谨慎，特别是已经有了大量用户的 APP，一起事故说不定就会遭受到非常惨重的损失，一家公司说不定就完了。

好在，随着技术的升级，开发app的成本越来越小。现在的技术只需要服务端配置好一些参数， 客户端预先把对每个参数的处理方法都写好。 然后在线上只要修改参数就可以在 APP 已经发布后还能对它有一定的控制力。

加上 JSPatch / wax/ rollout等代码的出现，iOS开发的学习成本越来越低，代码难度也一降再降，甚至一度成为了国内iOS开发者热衷使用的框架。这其中包含着不少我们熟知甚至每天都在用的app：

就目前国内的开发环境来看，每家公司都恨不得把自家的APP提早上线，以便尽早争夺市场甚至是谋取营收。然而加速上线的背后，难免会遇到一些bug或者部分产品经理“突发奇想”出来的需求。

这时，如果使用“原生应用”重新打包，将会面临着苹果平台的“二次审核”。虽然目前的审核仅需1-2天的时间就可以通过，但对于恨不得“周更”甚至是“日更”的国内APP来说，将“原生应用”重新打包上架显然不是最好的选择。

然而“热修复”的出现，恰好改变了这一局面。当iOS开发可以直接通过服务器推送并进行下载迭代，还可以避过苹果“二次审核”，这是多么一件令人激动的事情！正因如此，JSPatch / wax/ rollout 等框架也一度成为了国内开发者们最爱用的框架。

快乐的日子总是这么短暂，苹果一声令下，这些国内APP大概都要面临“回炉重造”，以适应新的审核制度。

然而国外友人却并不为此苦恼。

国外开发流程一般都依照着很好的规范来执行，上线之前还会做好充分的复查和测试，上线后bug普遍较少。在新闻中我们也很少会听到“国外APP因xx原因而惨遭下架”这样的新闻。而且好像也不是很符合外国人一劳永逸的心态，所以对他们来说，限制不限制热更新其实和他们没什么关系。

当然，更重要的是因为歪果仁最常使用的 Google Play 并不允许使用“热修复”框架。之前支付宝、美团等应用其实也大多都因为这个被举报，然后直接下架过，坊间还一度引发种种猜想和热议。