近日，苹果向所有开发者推送警告邮件，宣布未来将禁用APP内部的“动态分发”功能。并要求开发者在自家APP中删除JSPatch相关框架，否则APP将面临下架或禁止上架。
截止发稿，已有部分开发者新递交的APP受此影响被苹果审核部门拒绝。
这一动作，宣告着APP Store为“热更新”判了“死刑”，未来应用更新则将进入“原生”时代，用户需重新下载完整的新版数据包。
什么是“热更新”？
抛开复杂的技术语言，就是利用软件内的框架协议，允许软件从网络下载并运行调用可执行代码，对软件进行修改。
举个例子，就是大家平时打开《阴阳师》或者《王者荣耀》时，弹出的下载更新页面。▼▼▼
如果热更新被禁用，对于玩手游的上班族来说，不得不面临这样的情况：
在工作岗位上兢兢业业了一天，终于可以在公交地铁上玩上两把；
突然发现游戏有更新，需要下载完整的软件安装包；
然而由于APP Store的限制，大于100M的安装包只能在连接WiFi时下载；
满脸遗憾的你默默将程序关闭，叹了一声：还是算了吧，回家还得做饭看孩子呢。
然而更崩溃的，莫过于中国的“程序猿”们。
这次被禁的JSPatch / wax/ rollout热修复框架，由于代码命令简单，程序员的学习成本低，使用频次高，成为了许多国内iOS开发者非常热衷使用的一个框架。使用JSPatch的APP中，有很多是我们耳熟能详的▼▼▼
目前国内的开发环境，把不得自家APP早日上线盈利，难免会遇到一些bug或者一些产品经理“突发奇想”出来的需求。
如果使用“原生应用”重新打包，就面临着苹果平台的“二次审核”，即使这两年苹果加快了审核速度，但1-2天的审核周期（之前大约要7天），对于恨不得“周更”的国内APP来说，确实过于漫长。
由于“热修复”直接可以通过服务器推送并进行下载迭代，可以避过苹果“二次审核”，于是就成为了国内开发者们最爱用的一个框架。
可惜苹果一声令下，这些国内iOS开发者们，都要面临“回炉重造”，以适应新的审核制度。
为什么外国的开发者表示影响不大呢？
因为国外开发流程很好很规范，会做好充分的 codereview 和测试，上线后bug较少，往往很少需要进行热修复。频繁的更新迭代，不符合歪果仁眼中的“稳稳的幸福”。
当然，更重要的是歪果仁最常使用的Google Play也不允许使用“热修复”框架，支付宝、美团等应用都被举报然后直接下架过。
为什么苹果和谷歌禁用“热更新”的态度如此强硬，它究竟犯了什么错？
说到底，还是因为“热更新”从根本上破坏了官方应用分发平台“可控”与“安全”的底线。
在苹果的“开发者条例”中，明确规定了“所有执行代码都需要包含在App中，禁止下载代码到本地执行”。
显然JSPatch框架代码违反了这条规定。借助于这项技术，开发者可以避过官方应用商店的二次审核，许多国内开发者为了赶上架时间，钻了苹果审核的漏洞。
由于代码会在应用审核后改变功能，国内一些涉嫌违规的应用，往往是靠审核时关闭违规功能，审核后通过“热更新”代码来打开违规功能蒙混过关。
试想一下，本来你下的是一个消消乐的游戏，然而“热更新”后开屏给你推荐一些光屁股小姐姐的网站，俨然变成了个涉黄涉暴应用。
另一方面，JSPatch由于代码简单易上手，不仅方便了开发者，也方便了那些别有用心不法分子。
小编相信绝大开发者使用热更新只是为了“图方便”，不会添加恶意代码（最多暗改下极品爆率），但如果开发者没有做好热更新过程中传输的加密与校验，就很容易遭到第三方的“中间人”攻击。
早在2016年初，国际网络安全公司FireEyes就曾指出苹果APP Store内千余款应用使用JSPatch框架、存在严重的安全漏洞。▼▼▼
