关于苹果禁止采用JSPatch / wax/ rollout 热修复框架的app上架，你怎么看

Posted 2021-04-30 阿里云云栖号

最近一两周苹果加强了对app的审核，特别是警告去掉动态下发功能。那么苹果为什么会兴师动众，拒绝这种热修复框架呢？

其实不管是 JSPatch 还是wax和 rollout 等热修复框架，其原理都是通过 JS 脚本调用和替换任意 OC 方法，而js脚本转换oc的方法目前是比较低效的。其实从苹果的开发者条例中来看，苹果对热修复一直以来的态度都是不赞同也不拒绝，并且JSPatch 大多数都用于修复 bug（这也是为了快速修复bug，可能这动了苹果的奶酪），一直以来，苹果一直特别在意两方面：安全和体验。

体验

所谓体验，我们都知道，苹果一直以来都比较注重产品的品质和体验，特别是在乔布斯那个年代，苹果的每一个产品都可以说是划时代的产品，其体验一直受到广大用户的推崇，而采用JSPatch 等js注入的其运行效率往往达不到原生的效果，或者编译会加重手机的负担。

安全

在安全上，苹果一直以最安全的系统自居（闭源，大家懂得），但是前提是你必须遵循它的开发规范，但是采用JSPatch 等热修复框架之后，这种安全和可控正在被挑战。
举个例子，开发者接入的SDK里接入了JSPatch，SDK 作者对这些 APP 下发恶意脚本，这就造成了安全隐患。

原因

国外开发者比较少用热修复，是因为国外开发流程很好很规范，会做好充分的 codereview 和测试，上线后没什么 bug，不需要热修复。而国内版本迭代频繁，经常 出现因为某个小问题造成app奔溃，这就不得不提交新版本。特别是苹果在最近上线了灰度测试扫描代码，所以我相信苹果在以后肯定会加强对这方面的控制。

怎么办

热修复的需求很大，很希望苹果可以推出自己的方案，由系统做这个事是可以保证安全的，但从目前看起来可能性较低。

那么针对目前苹果对JSPatch的观点来看，我们只要不是滥用，应该是不受影响的，毕竟还是有例外的，诸如React Native/ 小程序这样用 JS 做功能的现在是不受影响的。那么针对目前已经使用了热修复方案的app，我们以后怎么做才能提高审核通过率呢？这里我提三个建议：

1.减少使用人数，降低影响面。

2.禁止 SDK 接入。

3.接入保证传输安全和只用于修复 bug。 第一点，出自我出发，严格遵守苹果的开发协议和流程。第二点和第三点减少第三方平台的接入，特别是一些小平台的接入，并多采用官方方案来管控。对于上述三种建议，如果可能的话希望可以跟苹果审核团队协商解决。

那么对于JSPatch等热修复框架，你怎么看？

·如于苹果此举，你是顶？是踩？来说说你的观点和看法。

·谈谈你开发的APP有没有使用热修复？现状如何？

·苹果此举后，大家的对策是什么？或是预测一下此事儿发展状况将是怎样？

点击左下角【阅读原文】进入参与话题讨论，将有机会得到以下奖品哦^^