在国外，本次警告事情其实受影响并没有那么大，在国外，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和JavaCore中可以加载远程代码，但不得改变应用的原本意图，从这个意义上说，其实热修复是可以被接受的，但热更新则不行。

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