@pockry 2017-03-12T20:35:33.000000Z 字数 5257 阅读 2489

苹果“热修复门”事件复盘、分析和展望

移动

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，甚至微信小程序都不是本次警告的打击目标。对于这些技术的开发者，从理论上来说是存在风险的。

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

一些思考

安全并不是禁止的理由

在本次警告事件中，苹果将安全风险作为禁止使用特定API的原因之一，但实际上并不能作为理由。因为使用这些API加载远程代码，也可以做到安全。并且，即使不使用这些API，仍然可以做到动态加载远程代码。如安全专家tombkeeper和蒸米在微博的讨论：

如果针对的是安全风险，应该去提醒那些还没有使用TLS的应用尽快实现。

当然，新的技术可能会带来安全风险，国外会为了这些风险而不使用新技术，国内更具冒险性，如果新技术能带来足够的收益就值得采用，安全用另外的方式弥补。

隐私与规则

在本次事件国内外开发者的反应中，我们可以窥到一些文化上的差异，国内外对于隐私、安全和规则的理解非常不同。

对于热更新这项技术，如果滥用，的确会带来风险，比如，开发者可以在通过审核后再使用被苹果禁止使用的私有API、收集用户隐私信息等等。国外的用户对于隐私的保护十分注重，苹果也在这个方面做过多轮宣传，甚至不惜对抗执法机构。隐私保护在国外被放在一个非常高的高度，是一个不能被触碰的底线。因此，只要热修复技术存在隐私风险，在国外的推广就会很艰难。在此次事件中，大部分国外开发者也都站在苹果一边，认为不应该使用热修复技术。

但在国内，隐私并不是一个主要问题。并且从实际上来说，有法律的威慑在，由黑客造成的隐私泄露并没有造成严重的社会问题。阿里的王坚博士在一次分享中说过，完全的隐私保护随着互联网的发展其实越来越难实现了，我们总会在某些地方留下不可消除的脚印，我们要做的是尽量降低恶意使用这些隐私的风险，而不是为了保护隐私而放弃创新和发展。

另外还有一点不同的是，国内外对于遵守规则的认同。事件发生后，国外开发者第一时间是指导如何去掉涉及的敏感API，Rollout的CEO也一直宣称自己是遵守规则的，React Native也宣称是遵守规则。而国内则是讨论苹果到底是如何发现的，如果去规避检查。

在一般情况下，国外的做法更为可取，我们应该去遵守规则而不是想着钻空子。但在本次事件中，规则本身是暧昧的，甚至苹果在执行上存在双标，因此不能一概而论。

苹果的双标

如果从最严格的角度去解读App Store的审核条款，它否定了一切动态加载代码的行为，而在开发者使用协议里，它规定在WebKit和JavaScriptCore中可以加载远程代码，但不得改变应用的原本意图，从这个意义上说，其实热修复是可以被接受的，但热更新则不行。

但实际上，热更新已经在移动平台存在了很长时间，并且将继续存在下去。

一个是在手游的开发中，热更新早已成为基础技术，对于小版本发布，以及为了配合运营，动态下发资源和脚本是业界通常的方案。这次苹果的警告邮件，基本没有涉及到游戏。Cocos2d-x游戏引擎的创始人王哲表示，因为游戏的热更新的代码都是跑在引擎范围之内，不会去改变与系统相关的默认行为，因此不受规则限制。不过，如果从字面上解释，这种行为仍然是违反条款的。

另一个就是React Native。React Native和它的热更新插件如微软研发的Codepush结合，可以做到动态改变应用的默认意图，与条款是相违背的。

苹果禁止了热修复而不禁止这些，并不公平。也让开发者不能知道苹果的底线何在，不能更好的遵守规则。

未来展望

移动平台动态化之路往何处去

这次警告事件无疑是对iOS平台Native动态化是一次严重打击，其影响甚至可能波及到Android平台，毕竟Google也是禁止加载远程代码的，并且执行更为严格，只是管不到中国的Android开发而已。

但是，动态化的刚需仍在，苹果既然打开了潘多拉的盒子，就很难关上了。国内基本都已经体会到了热修复带来的好处，让他们回到修Crash都要发版审核的蛮荒时代，已经是不可能了。Native动态化受到打击，人们会转向其它的动态化技术，如React Native，甚至是Web方案。

作为开发者，我们不能停止创新的脚步，我们有必要去不断的试错，去试探苹果的界限在哪里。创新，本来就是一件突破边界的事情。如果老是停留在苹果给我们划定的范围内，无论对于苹果，还是对于开发者，都不是一件好事。

广告时间

在6月份InfoQ举办的GMTC全球移动技术大会上，我们设置了Native动态化的专题，来探索iOS和Android上更多的可能性，我们不会停下脚步！点击阅读原文，进入GMTC大会官网。

阅读原文链接： http://gmtc.geekbang.org/?utm_source=infoq&utm_campaign=daqianduan&utm_medium=wechat