本文为转载文章
故事背景：
这两天，不少iOS开发群都炸窝了，原因是部分iOS开发者收到了苹果的警告邮件：
有开发者质疑可能是项目中使用了JSPatch、weex以及ReactNative等热更新技术。对于修复bug提交审核的开发者来说，热更新技术可以帮开
发者避免长时间的审核等待以及多次被拒造成的成本开销。但也给黑客留了后门，也就违反了苹果的安全和隐私政策。
不过这次苹果只是对使用热更新的应用进行了警告，并没有开发者反应产品因此问题被下架。
在苹果开发者论坛上，一位开发人员透露，他们的公司已经接到消息，称在删除这些“HotPatch”代码之前，苹果将不接受其应用更新。
分析说明：
从目前各方面反馈来看，苹果此次狠抓的是下发代码，所以JSPatch就被拉出来吃枪子了，JS等形式代码将被禁止。
WWDC后App Store Review Guide
Line更新 2.5.2 条这样描述：
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.
本条规定所有执行代码都需要包含在App中，不能下载代码到本地执行，所以OC或者JS形式的代码明显违反了这条规定，但苹果显然没有在
过去一年中对这条规定进行贯彻，直到今天才向相关开发者发出了警告。
对游戏本身有何影响?
这个问题其实有目共睹，在禁止热更新之后
1、游戏无法频繁更新功能、修复BUG，厂商在更新版本之前，可得长点心吧!
2、游戏更新后用户需要重新下载完整游戏，带来了用户流失和活跃度下降，特别是大包体游戏更为严重，用户要是动不动就下载个1G多的游戏，对游戏体验的伤害太大。
3、游戏更新后整体需重新经过苹果再次审查，造成审核周期增加。
是否有规避方法?
根据目前苹果进行审查的方式主要有两种：
一种是检查特定的类名，如JSPatch和Rollout，苹果会审查APP是否携带了这一类的库。
另一种是扫描特定的API，有规则将会检查这些 API 的参数是否可能由外部引入。
通过混淆JSPtach(替换JSPtach内部所有类和方法名)，或许是可以绕过审查蒙混过关。虽然苹果尚未明确惩罚方式，但在继续
HotPatch和开发者账号被封之间，还是提高点App稳定和Debug上多下功夫，Weex似乎也还有机会。
苹果开发者在去年就发现了由于JSPatch所引起的更新漏洞将被黑客利用，从而引起一系列损失，苹果对AppStore的优化也从未停止，无论开发者对于此次HotPatch的禁令是否存在各种怨言，按照苹果的以往原则来看：你们尽管骂，最后还不得管我叫爸爸!
开发者说：
舞小月：
苹果注重的就是流畅性和用户体验，混编做的东西肯定没有native的流畅，这就违背了苹果本来的意愿，被禁也是正常的，而且苹果自己的蛋糕为何要分给竞争对手？以前没混编的时候你该怎么做不还是做了，现在没有，不代表以后没有，就像之前没有混编，后来有了混编。新的框架苹果自然也会去完善，苹果既然做了这个决定，他肯定会优化自己的东西。
Gilbertat：
苹果爸爸会不会在自己的生态中搞死js啊
luohui8891：
我们也是昨天收到的，目前没有什么对策。我们的APP只是用JSPatch做热修复，并不修改应用的功能行为等（但我觉得Apple并不care这个）。
lsllsllsl：
没用RN没用JSPatch，同样收到警告。
luohui8891：
@tcathy 根据邮件里说是你下次提交前请去掉这样远程下载代码运行的机制。所以应该就是下个版本如果不删除就reject
Loooren：
早上收到邮件，itunesconnect站内信，电话通知....用到了weex
xiaofuyesnew：
昨天晚上微软发布了Visual Studio 2017，自带基于React Native的iOS开发功能。鉴于微软这两年来开源的力度，发布这一功能似乎是在抢占开发者的市场，基于vs2017，在非苹果上开发ios应用更容易了。所以，苹果在这个节骨眼发出这个警告邮件，就有点威胁现有开发者的意思。暗地里想跟微软互怼。
对于那些已经在学习RN、weex、JSPatch的同学来说，这是个悲惨的故事
从苹果的角度看，禁止应用使用热更新技术更多是为了保护用户隐私、数据安全以及其全力打造的生态圈。对于用户来说，出于安全起见，应谨慎授予应用权限；对于开发者来说，为了审核以及长远的用户体验考虑，不要轻易触碰苹果拉的那条红线。
