前言

3月8号，很多iOS群炸锅了，原因是不少iOS收到了苹果的警告邮件，在邮件中，苹果称开发者使用了动态代码更新技术，要求开发者删除相关代码，并重新提交一个新的 App 版本以供审核。

邮件中明确指出，违反了苹果开发者协议 3.3.2 节：

一个应用程序不应该下载或安装任何可执行代码。解释执行的代码可以在应用内使用，如果所有的脚本、代码，和解释器都被打包在应用内而没有被下载。前述内容的唯一的例外在于下载的脚本和代码使用了 Apple 内置的 WebKit 框架或 JavaScriptCore，并且对应的脚本或代码并没有改变这个应用提供功能和特性的主要目的，与提交到 App Store 的版本以及相应的宣传描述相符。

作为一个iOS开发者，又刚好手上有个KPI任务和热更新相关，所以特别关注这块。借鉴国内外大神们的分析和个人见解，写一些我认可的想法和对以后热更新的安全策略。

一些问题

1、苹果是不是完全禁止热更新技术？

事情已经过去了几天，可以看到苹果爸爸并没有进一步扩大“战果",受灾的开发者集中在使用JS-Patch或者Rollout类库，可以明确的看出苹果不会完全禁止热更新，当然苹果爸爸是不会公开说明这些的。

从事件的起因上，主要是由于国外大量APP使用Rollout.io热更新引发的安全性问题。国外具备更成熟的开发测试环境，另外苹果本身对APP审核速度的加快，热更新技术并不像国内这么"猖獗"，也没有国内这么"热衷"，所以相较于国内，国外热更新用的其实并不多，但可能外国民众自我隐私和保护、安全意识的高觉，苹果迫于压力不得不将Rollout.io砍掉，至于JS-Patch更觉得是被顺便砍了一刀。

2、为什么游戏热更新技术被理解为安全的，而JSPatch等热更新理解为不安全的？

从事过游戏开发的开发者，肯定接触过热更新，至少90%的游戏都支持热更新，像现在APP端热更新实现原理都来源于游戏热更新，但这次却没有一个游戏因为热更新被警告，所以从这可以看出，游戏热更新技术是被理解为安全的；反过来说，JSPatch等热更新理解为不安全的。

但，游戏热更新真的安全吗？真的和JSPatch这些热更新有本质的区别吗？

可以很明确的说，游戏的热更新和JSPatch这些热更新并没有本质上的区别，cocos2d-js，unity3D-js 等js热更新中就使用JavaScriptCore.Framework实现;而至其他像lua热更新也是类似基本上都是源于runtime，改写原有方法。。所以本质上他们并没有区别。所以，我更倾向于像Rollout.io CEO说的那样，这次仅仅是苹果对3.3.2协议的一次狭隘的偏见，热更新技术本身，苹果是不禁止的。

3、RN是否会受到影响，是否被苹果禁止？

RN近一年来备受关注，行业内大受好评，甚至像BAT等一些大公司都会有直接招RN的职位。RN的优点在于跨平台，仿原生，还有一点是热更新。RN用的语言是js，同时又能热更新，鉴于jsPatch被警告，很多开发者猜测，以后RN开发的APP是否被苹果拒之门外，然而事实证明，在github,RN社区里面，可以看到RN其实并没有受到影响，从这也可以看到苹果对热更新技术其实并不是禁止的。

从个人角度来说，RN的优势是非常明显的，相较于之前的跨平台框，html5等，RN不仅仅实现的跨平台技术，仿原生技术，另外还有重要的一点是性能上，对于大多数APP来说，比原生差不了多少。而3.8号微软新出的20周年visula studio2017版，对RN的支持，也可以看出微软对RN的认同，至于RN最后能不能大一统，我想还是有可能的。由于硬件不再是瓶颈，低一点效率的语言对最终用户来说感觉并不明显，但采用RN可以省去大量开发、维护、学习成本，大一统应该也是大势所趋吧。

一些猜想

1、苹果本身并不想砍掉热更新

热更新的优点，不仅仅实现了在线的bug fix，功能模块增加，同时在这个背后节省了大量测试人员成本和测试时间成本（因为即使线上APP出问题了，也可以通过热更新修复，测试必然就没那么谨慎），也减轻了苹果公司本身对APP审核成本（如果没有热更新，开发者就会提交新的APP），同时由于及时的热更新也为苹果创造了更多的利益（APP出问题了，等审核修复，中间的几天用户就不能为苹果创造利益了）。所以热更新对于开发者、苹果本身、用户都有很好的作用，可以大胆猜想，这次苹果只是迫于压力，或者只是看Rollout不顺眼，做了一次警告，当然里面肯定也有苹果对热更新的”猖獗“打击。

2、苹果自己不会做热更新

假如苹果自己开发一个工具，支持热更新，苹果还是得审核patch（不可能不审核）,这和开发者重新提交APP审核对于苹果来说是一样的，这样APP还是不能及时更新，唯一的好处可能是不用重新到APPStore重新下载，如果这样子，不管是对开发者来说并没有达到热更新的效果，同时对于苹果来说，还加重了审核成本，然而并没产生任何效益。所以，可以猜测苹果自己不会做热更新。

3、如何做一个符合苹果要求的热更新

从上文的论述中，虽然苹果不会明确公开说明--你们可以大胆的热更新，可以看到苹果本身对热更新并不排斥，甚至有那么点支持。其核心问题其实就是，如果出了问题谁背锅。如果开发者可以保证下载的patch一定是开发者自己本身创造的，出了问题开发者自己背锅，我想苹果审核者肯定会闭一只眼的。

像github社区中，对如何避免APP热更新被下架，有说针对dlopen()、dlsym()、respondingToSelector:、performSelector:、method_exchangeImplementations()几个方法的代码混淆，这实现上并不难，但谁也不能保证这是不是所有检测的方法，难道一次次提交APP测试 O(∩_∩)O？

我的个人猜想是可以采用类似android加固的方式，下载的patch增加一个壳，下载app后，去掉壳，保证patch的安全性；至于如何加壳，我想如果可以把开发者证书的信息包含进去，应该会更安稳点。

最后

天下熙熙，皆为利往。说到底，最终都是为了利益，至于是不是和我猜想的一样，也不能完全保证，对于大苹果的生态圈来说，也许并不像我所看到的那样。但从苹果对RN、游戏的热更新的模棱俩可，可见，只要对苹果有利，又不给苹果带来麻烦，不管你上层用什么语言开发，只要底层还是OC,最后还是通过APPStore，给大苹果创造利益，它也不会找你麻烦。

参考资料：

http://geek.csdn.net/news/detail/185602

https://baijiahao.baidu.com/po/feed/share?wfr=spider&for=pc&context=%7B%22sourceFrom%22%3A%22bjh%22%2C%22nid%22%3A%22news_3347847651371257825%22%7D

https://github.com/bang590/JSPatch/issues/746