前言
最近不少 iOS 开发者都收到了苹果的警告邮件，在邮件中，苹果称开发者使用了动态代码更新技术，要求开发者删除相关代码，并重新提交一个新的 App 版本以供审核。
邮件原文翻译如下：
尊敬的开发者，
您的应用，扩展程序和/或链接框架似乎包含明确设计的代码，能够在应用审核批准后更改应用的行为或功能，这不符合 Apple 开发人员计划许可协议和应用的第 3.3.2 节商店审查指南 2.5.2。此代码与远程资源相结合，可以帮助对应用程序的行为进行重大更改，与最初对 App Store 进行审核相比。虽然当前可能不使用此功能，但它可能会加载私有框架，私有方法，并支持未来的功能更改。
这包括将任意参数传递给动态方法（如
dlopen()
、
dlsym()
、
respondingToSelector:
、
performSelector:
、
method_exchangeImplementations()
）和运行远程脚本以便更改应用程序行为或调用 API 的任何代码，下载的脚本。即使远程资源不是故意恶意的，它也可能很容易被劫持通过中间人（MiTM）攻击，这可能对您的应用程序的用户造成严重的安全漏洞。
请对您的应用执行深入审核，并删除符合上述功能的任何代码、框架或 SDK，然后再提交下一个更新以供审核。
而上文提到的苹果开发者协议 3.3.2 节具体内容如下:
一个应用程序不应该下载或安装任何可执行代码。解释执行的代码可以在应用内使用，如果所有的脚本、代码，和解释器都被打包在应用内而没有被下载。前述内容的唯一的例外在于下载的脚本和代码使用了 Apple 内置的 WebKit 框架或 JavaScriptCore，并且对应的脚本或代码并没有改变这个应用提供功能和特性的主要目的，与提交到 App Store 的版本以及相应的宣传描述相符。
苹果警告邮件波及甚广，在 GitHub 的
JSPatch
和
react-native
项目下非常多的 iOS 开发者在讨论这件事，也因为苹果并没有具体指明，导致了大家的各种猜测。今天，React-Native 官方已经辟谣，确认不是 React-Native 的问题，而是 JSPatch / Rollout 的问题，而
JSPatch 作者 bang 也发文对此进行了回应
，并表示：
动态化还是处于灰色地带，严格来说 RN 是不符合规则的，但还是被允许，只要不给苹果添麻烦，苹果就不会管，JSPatch 因为前面提到的两点风险被管了，怎样做到使用并不给苹果添麻烦呢？
-
减少使用人数，降低影响面；
-
禁止 SDK 接入；
-
接入保证传输安全和只用于修复 bug。
第一点警告邮件和代码检查使得使用门槛变高了，显然会减少使用人数。第二点第三点只要有一个平台来管控，是可以做到的，可能的话希望能跟苹果审核团队协商。
至此，我们不禁要思考，苹果是不是完全禁止热更新技术了？为什么要这么做？对于这几个问题，白鹭引擎架构师王泽撰文分享了他的观点，并阐述了此事件是否会对手游开发产生影响，具体如下：
苹果是不是完全禁止了热更新技术？
并不是，目前为止收到警告邮件的开发者绝大部分使用了 JS-Patch 或 Rollout 类库，剩下未直接使用这些类库的开发者，目前初步估计很可能是在集成的第三方 SDK 中使用了上述框架。而未采用上述框架的热更新技术，目前为止并未收到影响。而绝大部分游戏引擎由于并没有调用这些类库，也自然没有受到影响。
当然，后续事态会不会进一步扩大，还需要看苹果接下来的策略。但是笔者认为，游戏中的热更新技术并不会受到苹果的禁止，作为一名技术人员，我们不讨论产品、商业等问题，只从技术角度来看，为什么 JSPatch 苹果认为是不允许的，而游戏引擎的热更新技术，苹果目前认为是可以的。
苹果为什么要禁止 JSPatch 等热更新技术？
JSPatch 的原理是，开发者编写 JavaScript 代码，利用苹果内置的
JavaScriptCore.Framework
执行，以实现热更新功能。这一点看似也符合标准，但是在技术上，存在着重大安全隐患，参考 JSPatch 的业务逻辑：
require('UIView')var view = UIView.alloc().init()view.setBackgroundColor(require
