这应该是软件开发最近两天最热的话题了吧。。。 O(∩_∩)O哈哈~
首先说一下这次受影响的第三方：
目前已经知道的有：
高德地图 已经更新了sdk V1.3.4 规避了问题
Bugtags 已经更新了SDK V2.2.1规避了问题 **
这里不得不说下，大厂就是效率啊，很快给出了解决方案。
还有rollout，react native，weex，JSPatch，个推 ,bugly with hotfix等。
也有说是使用dlopen(), dlsym(), respondsToSelector:, performSelector:, method_exchangeImplementations()这些个方法太多了。。具体原因不清楚，还得等苹果大大给出答案啊，谁让他是你亲爹来呢。。。
猜测的原因
苹果为什么这么做呢？苹果对热修复一直以来的态度都是不赞同也不拒绝，JSPatch 本身也并没有违反开发者条例，而且 JSPatch 大多数都用于修复 bug，提升 iOS 平台 App 的质量，对苹果也是件好事，为什么要禁？猜测原因有两点：可控和安全。
可控
苹果一贯作风是让所有事情可控，开发者能用什么不能用什么都尽量在自己的控制范围内。大多数人使用 JSPatch 修复 bug，或者弄一些临时运营的小功能配置，这些没有问题，但总会有少数用户使用 JSPatch 去调用私有API做些事，这是苹果不可控的，也无法知道有多少人这样做了。
不过其实在代码这块苹果其实一直可控程度有限，他会在提交时扫描你有没有用某些私有方法，但只要你对这些私有方法调用做一些变化，加解密字符串拼接什么的，就能绕过扫描，再通过后台配置调用，是一样的。JSPatch 只是让调用私有 API 变得成本更低更方便点而已，可控这里只是个小理由。
安全
去年 FireEye 分析了使用 JSPatch 的安全问题，当时也有文章回应了，再复述一下，主要安全风险有三点：
开发者自己本身对 APP 下发恶意代码。
开发者没有做好加密传输和校验。
开发者接入的SDK里接入了JSPatch，SDK 作者可以对这些 APP 下发恶意脚本。
第一点其实不算安全风险，因为开发者自己有恶意的话完全不需要借助 JSPatch。
第二点大多数用户使用 JSPatch 时都做好了非对称加密，保证不会在传输过程被第三方篡改。但这里技术上没法保证用户一定使用正确的加密方式，苹果无法知道有多少接入 JSPatch 的用户没有正确加密和校验，这是未知的安全隐患。
第三点在当时并没有什么第三方 SDK 接入 JSPatch，但现在像高德地图/个推等都接入了，如果他们要作恶，或者他们本身服务端被入侵，确实是个安全隐患。
iOS 平台是最安全的，也是最注重安全的，即使热修复带来了 App 质量更高的好处，也无法无视这里的安全隐患，现在 JSPatch 国内覆盖面很大，若出一个安全问题，会影响 iPhone 的声誉，因为这个风险，所以考虑禁掉。
Apple大大终于给出了回复：
The code referenced in our initial rejection message includes any code which passes arbitrary parameters to dynamic methods such as dlopen(), dlsym(), respondsToSelector:, performSelector:, method_exchangeImplementations(), and running remote scripts in order to change app behavior or call SPI, based on the contents of the downloaded script.
意思是：代码中引用我们最初拒绝信息，包括任何代码传递任意参数动态方法如dlopen(),dlsym(),respondstoselectorismemberofclass:performSelector:,method_exchangeImplementations(),并运行远程脚本为了改变应用程序的行为或调用SPI,基于下载脚本的内容。 都是不允许的。但是objective - c方法respondstoselectorismemberofclass:和performSelector:仍然是支持和允许的。
建议最近风声很紧，还没有得到确定的解决方案的时候，还是暂时规避掉这些敏感东西吧，根据苹果要求，收到警告的同学只需要在下次提交版本时去掉相关框架就可以，没有时间期限，目前也不会强制下架。否则你的App可能会被拒甚至被下架。
目前不清楚的点：（已经给出了解决方案）
1、是否不允许使用JSPatch或Rollout.js、React Native、Weex等框架？
（只要是运行了远程脚本，为了改变应用程序的行为或调用SPI，肯定是不行的啦）
2、AFN和SDWedImage等部分包括 such as dlopen(), dlsym(), respondsToSelector:, performSelector:, method_exchangeImplementations(),但是没有远程更新，这样能否使用？
（objective - c方法respondstoselectorismemberofclass:和performSelector:仍然是支持和允许的。）
3、第三方SDK，比如统计分析、crash收集、以及性能分析等，我们怎么检查他们有没有使用非法的方法？
我的方法就是，自己细致检查，并且关注对应的第三方网站给出的信息。
4、后期的解决方案是什么？
请深入审查你的应用，删除任何代码,框架,或sdk只要是包含上面禁止的内容；然后提交更新你的应用程序。
马上提交版本了，里面只用了JSPatch用于热更新修复BUG，但是没有收到苹果下发的警告邮件，准备不下掉JSPatch 提交看看，到底会不会被拒。 提了之后再来补充结果。
不过第一版，我还是要冒险测试下这个问题，一旦通过了呢。并且，没有了热更新真的好方啊，等我的消息吧 O(∩_∩)O哈哈哈~
结果：没有下掉JSPatch直接被拒了，删除之后在提交通过了。其中MJ和AFN等这些第三方库是没有问题的。坐等可以替代热更新的方案。
Apple 爹给出的具体回复：
The code referenced in our initial rejection message includes any code which passes arbitrary parameters to dynamic methods such as dlopen(), dlsym(), respondsToSelector:, performSelector:, method_exchangeImplementations(), and running remote scripts in order to change app behavior or call SPI, based on the contents of the downloaded script. The Objective-C methods respondsToSelector: and performSelector: are still supported and allowed. For example, they can be used to check OS compatibilty before using a selector. However, you should only pass selectors to these methods, which are specified at compile time. If you think you are using static selectors, it’s possible a third-party framework you’ve added to your app is not in compliance.
Please perform an in-depth review of your app and remove any code, frameworks, or SDKs that fall in line with the functionality described above before submitting the next update for your app for review
JSPatch 官方给出的解决方案：
讨论还可以看这些地方，已经closed了；
JSPatch Issues
react-native ：https://github.com/facebook/react-native/issues/12778
Weex ：https://github.com/alibaba/weex/issues/2875
JSPatch作者的看法
所以，最后的结果以及我们应该做的就是：
请深入审查你的应用，删除任何代码,框架,或sdk只要是包含上面禁止的内容；确保符合要求之后，提交更新你的应用程序。
完！！！ 继续关注中。。。
3月28日，JSPatch已经给出了解决方案：对应的解决方案
直接集成SDK的小伙伴可以更新了。
