苹果为什么不封杀 Flutter ?

开发者技术前线

共 1905字,需浏览 4分钟

 ·

2020-08-09 03:43

点击“开发者技术前线”,选择“星标?”

 在看|星标|留言,  真爱


     回复“666”,获取一份专属大礼包 


作者:mingyu ye

链接:http://tinyurl.com/te6zz45


对于 Flutter、RN、Weex、小程序这些跨平台解决方案的审核风险,曾与苹果团队专门沟通过这块。

RN、Weex、小程序:

首先 RN 和我们内部的 Weex 本身是类似的解决方案,都是期望团队开发业务的同学可以开发一套代码供多端使用,更多追求的是跨平台能力,在做这个方案的同时正好也具备了动态化能力,关于动态性方面本身具有一定的审核风险,这里明确表示是不合规的,参考审核规则 2.5.2 苹果动态性审核条款,只不过 RN 和 Weex 的风险不如当年的 JSPatch 那么大;


JSPatch 等热修复解决方案通过底层操作使得开发者可以用 js 等语言调用任意原生代码,这直接导致了用户 App 在苹果审核之后,依然可能做大范围的改动,这会使得苹果的审核机制形同虚设,想象下你一个明面上说是新闻类的 App,审核通过后摇身一变变成了博彩 App,你说合不合规,既影响 App Store 整体的体验,更会给苹果带来系统性的合规问题,这是一大封杀 JSPatch 的原因,至于官方说的安全性问题,确实可能存在下发脚本被黑客控制导致 App 出现重大安全隐患,但是都这么多年了,为什么苹果自己没有提供这样一个安全通道呢,答案显而易见审核才是其命脉和维护 App Store 生态的根本;


RN、Weex 苹果的建议是不提倡、不承诺不封杀,从我的理解是苹果对于这类相对低风险的方案,秉持的态度是观望,比如某天发现影响了他们的审核,就会毫不犹豫的封杀;如果在审核期间,通过这类技术动态改变页面,很有可能会被直接拒审。


至于小程序,其实本身是当年 H5 离线包的一个开发语法标准化的衍伸,本身确实也具备了跨平台和动态化能力,从苹果目前的态度来看,只要不做的特别过分,目前是可以的,尤其是目前各大平台都出了自己的小程序解决方案与开放平台的情况下,总不能把这些 App 都干了。

Flutter:

Flutter 与前面说的 RN、Weex、小程序最大的不同就是 Flutter 是一个跨平台解决方案,而非一个动态化解决方案,Google 的野心很大,想把 Flutter 打造成为新一代的移动端开发标准,在做任何事情时都会考虑合规问题,所以才会在考虑了 iOS 上动态化能力时,依然不考虑支持这个特性,因为一旦 Flutter 在 iOS 上具备了这个能力,也就存在了审核风险,这个审核风险是系统性的;


这点要说到国内外开发模式的不同,国外主张加强 CodeReview,国内主张小步快跑,快速迭代,有问题动态更新和热修复顶上,而苹果的审核速度即便一再加快,也难满足国内各大 App 的快速发版需求,正因为如此一再试探苹果的审核边界,最终在审核方面造成的问题和风险会逐步抵消掉动态更新和热修复带来的好处,当然不同 App 有不同的大环境,未来 App 也一定是朝着更合规的方向去发展;


苹果表示 Flutter 目前没有合规上的风险,因为本身就不是一个动态化解决方案,但一样秉持不提倡、不承诺不封杀,因为 Flutter 的崛起会吃掉苹果 App 原生开发人员的份额,苹果不建议使用官方以外提供的 Native 开发方案,苹果是绝不能容忍开发人员的大面积消失,一旦这种情况发生,苹果的生态就会遭人掣肘,这是苹果爸爸就会出来保护苹果 App 原生开发人员,这个时候也就是 Flutter 份额降低影响力降低的时刻,苹果也在不断推行 Swift 和 SwiftUI 等对原生开发人员更友好的解决方案,力图抵挡住各跨平台解决方案对苹果 App 原生开发人员的蚕食。



END



前线推出学习交流群,加群一定要备注:
研究/工作方向+地点+学校/公司+昵称(如移动端+上海+上交+可可)
根据格式备注,可更快被通过且邀请进群,领取一份专属学习礼包



扫码进群,免费大厂内推、高质量技术交流




END


点个在看吧

浏览 37
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报