关于苹果警告

2017-3-9

昨天早上 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 的安全问题,当时我也写文章回应了,再复述一下,主要安全风险有三点:

  1. 开发者自己本身对 APP 下发恶意代码。
  2. 开发者没有做好加密传输和校验。
  3. 开发者接入的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 的功能。

滥用

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

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

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

怎么办

接下来如果还想用 JSPatch 怎么办?我没有跟苹果审核团队交流过,不知道他们的想法,短时间内是先不要用,后续再看情况。

热修复的需求很大,很希望苹果可以推出自己的方案,由系统做这个事是可以保证安全的,但现在看起来可能性较低,国外需求量不大,苹果也就不会重视这个需求,何况目前在大力推 Swift。

对于 JSPatch,苹果应该是扫描可执行文件里的关键字,从技术上说是很难禁掉的,可以做各种混淆去绕过检查,但若下发时被查到,会有政策风险,政策有待观察。

实际上动态化还是处于灰色地带,严格来说 RN 是不符合规则的,但还是被允许,只要不给苹果添麻烦,苹果就不会管,JSPatch 因为上面提到的两点风险被管了,怎样做到使用并不给苹果添麻烦呢?

  1. 减少自行接入的使用人数。
  2. 禁止 SDK 接入。
  3. 接入保证传输安全和只用于修复 bug。

第一点警告邮件和代码检查使得自行接入 JSPatch 门槛变高了,显然会减少使用人数。第二点第三点只要有一个平台来管控,由平台保证安全性以及扫描下发的脚本,禁止私有API调用,禁止大量脚本下发,是可以做到的,可能的话希望能跟苹果审核团队协商。

附上 JSPatch 平台初定的解决方案

分类:互联网
评论

*

*

2017年3月9日 11:52

1 让自己的APP少点用户?
2 JSPatch是开源的,代码你可以自己修改,问题一样被警告.
3 这个就见仁见智了,你说时修BUG,APPLE会信吗?

2017年3月9日 11:56

@decwang
1. 是接入的APP少点
2. 若有平台控制,不允许自行接入,可以控制不准SDK接入
3. 若有平台控制,可以像苹果一样扫描脚本是否有私有API调用

2017年3月9日 12:00

那集成SD和AF库的App还能审核过么?

2017年3月9日 12:06

持续关注

2017年3月9日 12:11

没啥好说的,热修复对于一些小公司,测试人手不足时修复一些小bug非常有用
希望苹果能有自己的热修复机制吧

2017年3月9日 12:27

@bang
对程序员和产品来说,修BUG是个强需求,只要你的平台可用,人们会一窝蜂一样涌过来的.

2017年3月9日 13:08

@decwang 你说得也对,第一点应该改为减少自行接入的人数,有平台控制的用户保证安全和不滥用,人数多也不是问题。

2017年3月9日 13:16

不知道是否跑题@bang,如果这几天有人收到 Apple 的警告,并且提交了审核,希望分享一下审核的结果

2017年3月9日 13:48

在 iOS 这样一个平台上,当一项新技术各大厂商、开发者皆来参与时,苹果势必会监管。但堵死不会,所以我们下一步需要的就是平台管控,即为治本。只是这过程中,成本太高,时间太长,所以当下有何治标之策呢?

2017年3月9日 13:52

而『看到有一些人拍手称赞,赞的理由不是说苹果维护了平台安全,而是:1.国内开发方式low,2.产品经理滥用。』,其实王健林之前演讲中有一段话说得很对,具体可看:http://mp.weixin.qq.com/s/5hCblywnaSjqC936INabwA

2017年3月9日 14:05

iOS 这边禁掉没啥可说的,关键是 android 可以热更呀~这样以来,开发 iOS 的成本更高了。希望苹果能重视这方面的需求,搞一个官方的解决方案出来。

2017年3月9日 14:09

『JS没事,iOS 开发该失业的还是失业』,说的太对了。

2017年3月9日 14:10

支持bang哥!

2017年3月9日 14:25

同样希望国内的 app 增加质量,而不是增加各种功能。

2017年3月9日 15:22

facebook app里并没有使用RN,他们只是将RN用在了极个别小app内。facebook吃过hybird的亏,所以他们现在非常尊崇native开发。这是你首先要了解的情况。

2017年3月9日 15:24

微软这个low货,竟然开发了codepush热更新插件。

2017年3月9日 15:25

@chentoo 是因为性能和体验优先才尊崇native开发,而不是开发方式,另一篇文章里也说过了。

2017年3月9日 15:55

邦哥,挺住!你用JSPatch 改写了苹果的审核历史,让世界向前进了一步,无论是安全还是机制,都会推动苹果去思考怎么适应这么大的动态修复需求!!!

2017年3月9日 16:03

很喜欢JSPatch里面OC端到JS端方法和参数的调用方式,比原生的好用太多
能不能出个阉割版的?我的APP没有用到热部署功能,用的JS来写业务逻辑。

2017年3月9日 19:52

总结的到位,我们三天前提交的一版纯原生的IOS应用,目前还是在审核中的状态,如果苹果效率能够再提高一点,谁想那么麻烦用热修复呢,苹果更应该从自身来找问题

2017年3月9日 19:58

关于同样存在风险的RN和Code-Push,我猜是因为苹果不敢对Facebook和微软这样的大公司下手,真那么干很有可能要吃官司的

[…] JSPatch 的作者寫了一篇公告:关于苹果警告,勸大家先不要用避個風頭。也表達希望如果可以 Apple […]

2017年3月10日 10:35

1、安全、可控是最大的因素,没什么问题。
2、审核速度没有慢到要背锅的程度吧。

2017年3月10日 14:04

审核已经被拒了

2017年3月10日 15:08

『JS没事,iOS 开发该失业的还是失业』,呵呵,大牛就是大牛。

2017年3月13日 13:31

ReactNative&&weex&&小程序,他们对于原生API的调用是有限的,JSPatch、wax、rollout 并没有API的限制 ,这篇文章结尾处说的很对http://geek.csdn.net/news/detail/185602

[…] 关于苹果警告 […]

2017年3月20日 15:47

支持bang哥!我觉得JSPatch挺有价值,虽然没用JSPatch,但也是被Performance – 2.5.2这一条给打下来了,最后把项目里面用到method_exchangeImplementations 的代码注释掉,最后能正常上架。

2017年3月22日 10:39

头一次看Alert这种东西拿Web前端写还得写一大套组件的玩意儿。 就这么麻烦的东西也配说iOS能失业?失业的总是没有基本功不扎实的,jser浮躁的态度拿框架疯狂吹nb的本质还是不变的。

2017年3月22日 10:49

JS这种东西坑多的东西“熟练”jser早就当做“丰富的经验”都hold 住了。
然而好用的东西应该一上来就好用而不是要“丰富的经验”。
JSPatch算不上好的“开发方式”,一不小心写了个全局变量bug都不好查,哪管换个有类型语言做这个也行。
至于low b的iOS开发,清一色strong ARC丝毫不了解、API制定渣渣、设计模式不会用、mach底层不了解之流你让他写别的该失业也失业。

2017年3月22日 10:58

最后一条评论,我想反驳只有{开发方式}一栏,没有说JSPatch存在的意义不重要,只是觉得“开发方式”换做“存在意义/更多赋能”才能正确做大众的导向。

2017年3月22日 17:49

@AntiMoron 。。你缺乏幽默感