一位JSPatch开发者谈来自苹果的警告

苹果 jspatch| 2017-03-10

昨天早上 iOS 开发者们陆续收到苹果邮件，警告去掉动态下发功能，覆盖面很广，内容没有明确指示是什么库，导致大家各种猜测。

其实上周已经有少量用户收到苹果这份警告邮件，当时还以为是特例，现在看来是在灰度测试扫描代码，可见这事苹果应该讨论已久，并专门排期开发测试了扫描程序，直到昨天才正式上线。

从各方信息看起来，很不幸主要禁的还是 JSPatch / wax / rollout 这样的热修复框架，特点是可以通过 JS 脚本调用和替换任意 OC 方法，而像 React Native/ 小程序这样用 JS 做功能的暂时不受影响，Weex 不确定，至于其他库像 AFNetworking / SDWebimage 用到那几个接口的，应该只是误伤。

根据苹果要求，收到警告的同学只需要在下次提交版本时去掉相关框架就可以，没有时间期限，目前也不会强制下架。

为什么

苹果为什么这么做呢？苹果对热修复一直以来的态度都是不赞同也不拒绝，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 的声誉，因为这个风险，所以考虑禁掉。

反应

这个警告出来后，国内开发者有各种反应，各种表情贴图还挺搞笑的，不过大家放心，JS 没事，iOS 开发该失业的还是失业:)

看到有一些人拍手称赞，赞的理由不是说苹果维护了平台安全，而是：1.国内开发方式low，2.产品经理滥用。这里我有一些想法说一下。

开发方式

他们说国外开发不理解国内为什么要用热修复，国外很少使用，国外开发流程很好很规范，会做好充分的 codereview 和测试，上线后没什么 bug，不需要热修复，也不会有产品经理乱提需求，迭代没像国内这么快，使用热修复是本末倒置，不去考虑提高 APP 质量，国内开发方式太 low，国外的才是正道。

这里有个问题，就是什么是好的开发方式？以什么标准界定？上面的说法可以看出他们是把工程的严谨性，流程的规范性作为好坏的依据。虽然我是个程序员，觉得工程严谨和流程规范确实是好东西，但我比较实用主义，更倾向于以结果作为标准，也就是能不能更低成本更高效地开发出质量更好的产品作为标准。

如果我使用热修复能以更低的人力成本（工程师能力和薪水不如国外，人数少），更高效（测试时间缩短，不需要覆盖到0.01%几率出现的 bug / crash ），做出质量更高的产品（ bug / 特殊情况和需求反应速度快），为什么不是一个更好的开发方式呢？

另外客户端的开发方式本身就是落后的，不利于快速迭代，无法对线上产品有控制权，参考另一篇文章。这也就是为什么 Facebook 一开始要用 Web Hybird 的方式开发，现在又要做 React Native。热修复是这种落后开发方式的弥补。另外我没在国外公司工作过，但感觉他们对bug的容忍程度还是比国内高的，对比一下 IAP 和微信支付的失败率，做过的人都知道。

还有一个声音说国内的人喜欢违反规则，钻空子太不老实。首先前面也说了热修复的方式并没有违反规则，完全符合开发者条例，其次国外也有热修复 rollout，最后如果从开发者条例来说，React Native 反而是违反规则的，因为主要用途动态添加和修改 App 的功能。

滥用

另一个说法是上了热修复后产品经理来劲了，产品时不时想到一个功能配置说上就上，开发者弱势只能跟着上。

这种情况在我这边团队还没遇到过，我的想法是：如果要上的功能配置对产品是有好处有必要的，开发维护成本又低，为什么不上？如果要上的功能配置是无关紧要的，或者开发维护成本太高，为什么不能讲理拒绝？

开发者把原因定位为自己“弱势”，就把自己从团队剥离开了，变成对人不对事，这种团队氛围是挺糟糕的，而这个锅也不是产品经理的。大家做的事都是为了产品更好，应该不会有那么多故意刁难不讲理的产品经理和老板。至于怎样界定对产品有没有好处和有没有必要，以及开发成本高低，这得自己协商了，以我们团队的做法是以做这个事的性价比计算。