苹果「热修复门」事件复盘、分析和展望

3月8日，很多iOS开发者收到了苹果的警告邮件，声称其App违规使用动态方法，责令限时整改。一时间众说纷纭，有说是针对热修复的，有说是RN也收到警告邮件的，恰逢微软发布Visual Studio 2017，推出了开发React Native for iOS功能，还有说苹果借此来反制微软的。

到底事情真相如何，目前都有哪些动向，会带来什么影响，让我来给大家盘点一下。

按大概时间梳理整个事件，包括相关各方的反应如下：

• 3月8日上午，有iOS开发者收到苹果警告邮件或提交App审核时收到拒绝反馈，内容称：检测到开发者的App违规使用动态方法，包括 dlopen() 、 dlsym() 、 respondsToSelector: 、 performSelector: 、 method_exchangeImplementations() 等，并执行远程脚本，违反了开发者计划许可协议3.3.2以及App Store审核指南条款2.5.2；同时，远程下发脚本可能发生中间人攻击，造成安全风险。苹果责令限时整改。

  

• 开发者发现收到此类警告的App大多数是集成了JSPatch、Rollout、React Native、Weex等项目，于是前往各开源项目的Github上发issue，并在官方的苹果开发者论坛上发帖，试图获得更多消息。

• React Native开发者澄清并不是它导致的问题，也不是其代码增量更新服务Code Push或Expo的锅，但有些RN的插件使用了上面提到的方法，React Native开发者建议用户不要使用这些插件。在警告邮件之后，部分开发者报告React Native开发的App通过审核。随后，开发者逐渐将目标锁定在JSPatch和Rollout这两个热修复工具上。

• 滴滴出行iOS动态化项目DynamicCocoa作者孙源在发布微博，猜测了苹果如何发现使用这些方法的，并表示DynamicCocoa开源计划暂缓。（不过他之后删除了该微博）

• Rollout CEO Erez Rusovsky发表声明，表示他们试图和苹果沟通，认为他们并没有违规，只是“苹果以一个更狭隘的角度去解读现有的规定”，不过他也承认在在苹果转变态度之前，自身无法解决目前面临的问题。

• JSPatch作者发布博客，让开发者暂时不要接入JSPatch，并表示希望看到苹果官方的热修复方案。其后，JSPatch官方的补丁托管平台JSPatch.com也发表文章，让用户发布去掉JSPatch的新版本。在此之前，有部分SDK接入了JSPatch，也纷纷发布了去掉该库的新版本。

值得一提的是，苹果在警告邮件之后，并未有针对该事件的官方回复，有人咨询了已离开苹果的Swift创始人Chris Lattner，他表示对热修复没有看法。

苹果在发送警告邮件之后，社区一直在寻找官方答案，但苹果并没有进一步解释它为什么这么做。开发者只能猜测。

本次涉及到的条款包括：

苹果开发者计划使用协议3.3.2：

Except as set forth in the next paragraph, an Application may not download or install executable code. Interpreted code may only be used in an Application if all scripts, code and interpreters are packaged in the Application and not downloaded. The only exceptions to the foregoing are scripts and code downloaded and run by Apple's built-in WebKit framework or JavascriptCore, provided that such scripts and code do not change the primary purpose of the Application by providing features or functionality that are inconsistent with the intended and advertised purpose of the Application as submitted to the App Store.

App Store审核条款2.5.2：

Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code, including other iOS, watchOS, macOS, or tvOS apps.

如果单从邮件内容理解，苹果此举是为了严格执行其审核条款，不过在JSPatch如此广泛使用，Rollout甚至成立创业公司来做这件事情的现在才打击，不得不说苹果的反应有点迟钝。并且苹果在发布警告之前，并未与社区进行沟通，至少Rollout和JSPatch都没有接触过。我们想要问，苹果是否真的了解开发者的需求？

从结果来看，最受警告影响的是Rollout和JSPatch两个热修复工具，以及其它类似能绕开苹果审核改变App默认意图的做法。它们都属于Native动态化的范畴。

按审核条款2.5.2的内容，苹果要求应用不得下发可执行代码，不得绕过审核，此举是为了加强苹果审核的权威性。

在国外，本次警告事情其实受影响并没有那么大，在国外，iOS平台热修复或热更新并不流行，Rollout的声明里，本次只有数百个App、数百万最终用户受到影响。

但在国内，这一数字要远远超出。去年以来，凡是公开分享过iOS应用架构的，都将热修复作为其基础设施之一，可以说大部分头部应用都有使用JSPatch或类似方案。本次受影响的国内App数以千计，覆盖的人群则包括几乎所有iOS用户。

更长远的影响是，热修复对一个团队的开发流程和节奏紧密相关，很多团队都必须修改相应的开发流程来适应变化。

据网友猜测，苹果可能是全量扫描符号表关键词，看是否使用了敏感API，以及检查是否使用特定的类名（JSPatch和Rollout的），依据是有些JSPatch用户做了一些混淆，没有收到警告。

正确的态度应该是：

既然同意了苹果开发者协议和App Store审核条款，就应该遵守苹果的规定，去除苹果提到的敏感API，不要使用热修复或其它类似方案。

这其中，特别是第三方SDK的提供商，除非本身是为了提供热修复功能的，否则不应该使用热修复，这是非常不负责任的做法，SDK应该仅提供稳定可信赖的功能，不应该在运行时动态修改其代码。

不过，问题在于苹果的审核条款是比较暧昧的，比如同样有违反审核条款嫌疑的RN、Weex，甚至微信小程序都不是本次警告的打击目标。对于这些技术的开发者，从理论上来说是存在风险的。

因此，如果开发者能理解并接受使用这些技术的风险，那么可以继续使用。甚至热修复技术，本身对于研发非常有帮助，如果愿意承担风险，也可以继续使用，当然，前提是你不被苹果抓住。