“倒反天罡押注 React Native 6 年后Shopify 又回到了原生开发”——我看到这条消息时的第一反应和评论区里大多数人一样暗叫一声“这也能回头”毕竟当年 Shopify 高调拥抱 React Native 的时候可是被很多人当成跨平台方向的标杆案例来引用的。如今说走就走等于当着全行业的面承认我们当年那套跨平台路线走到今天不划算了。我做了十来年移动端技术方案选型看到这条消息倒不觉得震惊反而觉得这是一次特别好的“群体复盘样本”。这篇不打算写“RN 已死”或者“原生永远滴神”这类情绪化的东西而是想把 Shopify 这六年到底经历了什么、官方公告里哪些话是客套、哪些话是真心、技术账和经济账分别怎么算完整拆一遍。适合这三类朋友阅读正在纠结 React Native、Flutter、Kotlin Multiplatform 和原生怎么选的技术负责人正在维护 RN 项目但被性能和兼容性折腾得够呛的开发者以及只想吃瓜但想从案例里读出点门道的人。下面我会先把 Shopify 的六年路线串起来再从技术原理层面复盘它踩过的坑最后聊聊这次“倒反天罡”对整个跨平台技术栈格局的影响。1. 先复盘一下Shopify 这 6 年走了一条什么路1.1 2018 年的选择为什么一家电商巨头会押注 React Native2018 年前后移动电商的竞争已经白热化。Shopify 不是单纯做一个消费者购物 App它的移动端要同时服务几百万商家的日常经营处理订单、管库存、看数据分析、联系客服、处理物流。这意味着移动端必须同时覆盖 iOS 和 Android。如果按照传统原生方案每端一套完整团队从 UI 到业务逻辑全部写两遍迭代速度天生减半。当时 React Native 的生态已经不算小了Facebook 自家 App 里大规模使用社区热度高第三方库也在快速增长。对 Shopify 来说RN 最诱人的点在三个地方第一业务逻辑写一份双端同时跑第二能用 JavaScript 生态里的工具链招人和培训成本相对可控第三动态更新能力比纯原生发布的节奏更灵活对“快速上新功能”的电商业务非常友好。所以要准确理解这个决定不能把它简单理解成“Shopify 不懂原生”。恰恰相反做过大型系统的人都知道原生质量更好。但当时 Shopify 没有资源在 iOS 和 Android 上各养一支完整的原生团队跨平台是资源约束下的理性选择不是什么信仰选择。这一点非常重要因为它决定了后面故事的所有走向。1.2 六年里的投入与扩张从“先跑起来”到“跑得更重”从 2018 年宣布切到 React Native到近期宣布迁回原生中间差不多六年时间。这六年里Shopify 的移动团队干了不少事核心商家端、消费者端都用 RN 做了重写大量功能在这套跨平台框架里完成交付移动工程团队规模也从最初的小几十人一路扩张到了百人上下。这里有个关键信号值得所有人留意当移动团队只有二三十人服务的是需要快速迭代的新业务时RN 的“一份逻辑跑两端”确实能让公司跑步前进。但团队扩充到百人规模、产品线变得越来越复杂以后跨平台框架的边际成本会快速上升。人越多分工越细平台差异带来的沟通成本和适配成本就会把代码共享那点红利一点点吃回去。另外必须补充一点这六年里 React Native 自己也在剧烈演进从经典的 Bridge 桥接架构到后来的 Fabric 渲染器、TurboModules、JSIJavaScript Interface每一次演进都意味着存量项目要跟着迁移、适配、重构。这些成本不会消失它们只是被记在了跨平台选型的长期账单里等到某个临界点一次性爆发。2. 宣布回归原生不是拍脑袋是账算不过来了2.1 官方表态里的关键信息翻译成大白话是什么Shopify 工程团队在官方博客里宣布未来的移动端开发将转向原生技术栈iOS 用 SwiftUIAndroid 用 Jetpack Compose。团队特别强调了一句话大意是“这个决定不是对 React Native 的否定而是对 Shopify 自身需求的回应”。这句话看着像公关辞令但实际信息量很大。翻译成大白话就是我们自己算过账了在 Shopify 当前的业务规模和产品复杂度下RN 已经不是最划算的选项了。它不是不好而是对我们的“账”来说不再合适。为什么账算不过来了核心原因有四条。第一双平台团队已经成长起来了不再缺原生人力跨平台节省的那点人力红利不再是决定性优势。第二产品复杂度上来了电商 App 不是表单工具它有大量图片浏览、长列表、动画、扫码、地图、支付、推送这些和系统硬件深度打交道的场景原生 API 明显更顺手。第三平台差异化成了竞争点iOS 和 Android 用户对交互的预期完全不同统一代码反而让两端产品都做不到最顺手的状态。第四维护桥接层和原生模块的隐性成本非常高凡是想在 RN 里用系统新能力都要等社区库更新或者自己写原生模块等来等去最后往往等成了自己维护。2.2 从“银弹”幻想到“用脚投票”技术选型是对错题还是阶段题看到这里很多人会问既然原生优势这么明显那 Shopify 当年是不是选错了这就是典型的“用结果倒推过程”的误区。RN 给 Shopify 带来的初期效率优势是真的抢出来的市场窗口也是真的。如果没有跨平台方案2018 年到 2020 年那段高速增长期里移动端是否能同时覆盖两个平台、按时交付那么多商家功能可能都是问号。技术选型在本质上不是一道对错题而是一道阶段题。同一个方案在团队 20 人时是良药到团队 100 人时可能是约束在产品快速验证期是加速器到精细化运营期可能是瓶颈。Shopify 这次不是“承认当年错了”而是“承认阶段变了”。这是我读那份公告时最明显的感受。3. 从技术层面复盘React Native 在 Shopify 进了哪些坑3.1 启动白屏电商 App 最不能忍的性能短板热搜词里一直有“react native 启动白屏”这真不是我编的这是 RN 开发者普遍绕不开的一个痛点。要理解白屏得先看 RN 冷启动的大致流程原生容器先启动然后加载 JavaScript Bundle初始化 JS 运行时再通过桥接或者 JSI 把原生视图和 JS 逻辑绑起来。这个流程里原生 UI 不能先渲染JS 还没跑起来的话用户看到的只能是一块白屏。为了缓解这个问题RN 生态里出现了一堆方案改用 Hermes 引擎加快 JS 执行、把 Bundle 拆成主包和异步包、首屏先用原生骨架屏顶着、提前预加载 JS 环境。这些方案都能改善但很难达到原生那种“点开即见内容”的体验。对 Shopify 这种用户每天高频打开的 App 来说启动白屏的每一毫秒流失的都是真金白银转化率上的损失是可以用数字算出来的。这里说句公道话RN 新架构本来就是要改善启动性能的Fabric 渲染器和 JSI 的引入也确实把性能往前推了一大截。但问题在于存量项目要吃新架构红利必须先完成一次大迁移。对一个业务模块极多、牵涉支付和物流的大型 App 来说这次迁移本身就是一次全身换血风险和时间成本都很高。3.2 共享代码的红利与反噬写一次跑两端还是“写一次调两端”RN 的核心卖点一直是“写一遍跑两端”但真正做过 RN 项目的朋友都会有体会业务逻辑层共享确实很爽UI 层的共享却没那么美好。iOS 和 Android 的手势、导航、键盘、滚动惯性、返回机制都不一样为了跨端组件库要做大量兼容代码里经常出现“if 平台写两套分支”的写法只是这两套分支住在同一个文件里而已。这还不是最让人头疼的。跨层抽象一旦出问题排查的时候得同时懂 JS 层和原生层一个偶发崩溃可能查上好几天。Shopify 团队到了后期平台级功能需求越来越多这种“双端兼容 桥接调试”的复杂度已经明显压过了共享代码那部分红利。代码共享的初衷是减少工作但在复杂度累积之后它反而制造出了新的工作。3.3 平台差异化需求彻底压倒了跨平台需求电商类 App 为了做转化率会不断尝试新交互3D 商品展示、AR 试戴、直播购物、自定义相机扫码、复杂的过渡动画。这些能力在原生平台上可以很顺畅地调用系统 API但在 RN 上常常要先确认社区有没有对应的原生模块没有的话就得自己写写完还得双端适配。更微妙的是苹果和安卓两个平台的产品思路已经越来越不一样了。iOS 用户很吃灵动岛、Widget、系统级分享这一套Android 用户则依赖返回手势、Material You 动态配色、桌面小组件。当一个平台想做出“只有这个平台才有的贴心体验”时跨平台框架反而成了捆住手脚的绳子。Shopify 最终的选择是保体验、保差异化用原生释放平台能力这在小步快跑阶段很难想到但一旦想明白就很难回头。3.4 新架构迁移与依赖维护RN 自己也在过河但船票越来越贵再给 RN 说句公道话过去六年它的技术演进其实很大。Hermes 引擎、Fabric 渲染器、TurboModules、JSI都是实打实的性能提升。但核心矛盾在于这些新东西要起作用你得先迁移而迁移会牵动几乎所有原生模块和第三方库。对 Shopify 这种业务规模而言这个迁移成本高到会让人怀疑“是不是重写原生反而更便宜”。第三方库版本的跟进速度也是硬伤。新架构出来很久很多老牌库还是只支持旧架构有的库升级后 API 大变样一升级就要做一轮全局回归测试。大团队往往发现与其等社区更新不如自己维护一份更靠谱。当“自己维护库”这种事多起来以后跨平台所节省的开发量其实已经悄悄被抵消了一大半。4. 回到原生之后真的一切都变好了吗4.1 团队和架构的调整拆分不是内耗而是重配资源回到原生不是一键切换。Shopify 的移动团队直接拆分成 iOS 和 Android 两个团队分别基于 SwiftUI 和 Jetpack Compose 构建。这个调整一定会带来招聘策略的变化不再要求候选人“两栖”样样通而是更看重在单一平台上的深度。但这里有个很多人忽略的细节SwiftUI 和 Jetpack Compose 都是声明式 UI 框架它们的开发理念和 React 那一套非常像组件化、状态驱动、声明式布局。也就是说当年 Shopify 团队在 RN 项目里积累的“响应式思维”并没有完全作废它只是把视图层和业务逻辑放回平台原生来实现。这种平滑过渡说明技术栈上的“回头路”未必是彻底推翻重来。4.2 原生开发带来的可感知提升以及我的一些冷思考回归原生之后最直接的变化是首屏加载和页面切换的流畅度。没有 JS 引擎启动的等待没有桥接转发的性能损耗页面基本能做到即点即开复杂动画和长列表滚动的掉帧明显减少深度系统能力比如相机、系统支付、健康数据可以直接走官方 API稳定性和可维护性都上了一个台阶。但我也要泼一盆冷水原生不是没有代价。同样的功能需求两个团队各写一遍开发量确实变大两边产品细节还可能出现轻微不一致。只是对 Shopify 这个体量的公司来说这笔“多写一遍”的钱换来了两套平台各自更好的体验和更可控的工程质量。某种意义上它是把当初省下的钱连本带利还回去了。这个选择谈不上华丽但很务实。5. 倒反天罡背后的行业信号React Native 还有没有未来5.1 别急着给 RN 开追悼会中小团队依然是它的主场先说结论Shopify 因为体量和业务复杂度放弃 RN绝不等同于 RN 没有未来。大量独立开发者和早期创业团队依然在靠 RN 快速验证产品一套代码同时上架双端用人成本是实打实的低。我也见过不少项目用 RN 从 0 做到百万用户技术选型并没有成为业务瓶颈。RN 的生态短期内也不会崩塌。Meta 还在持续投入社区依然活跃全球范围内 RN 的应用数量依然庞大。跨平台需求是真实存在的不是哪家公司一宣布离开就能抹掉的。那些把“Shopify 离开”解读成“RN 宣判死刑”的说法更多是为了流量而不是为了技术事实。5.2 跨平台方案的新常态工具化而不是神化这次事件真正敲掉的是“跨平台万能论”这块牌子。以后再做技术选型RN、Flutter、Kotlin Multiplatform、原生就是四件不同工具按需求和阶段去选。Flutter 在渲染一致性上做得确实好引擎自绘 UI 让双端观感高度统一但它和系统深度交互时同样有桥接成本同样面临平台差异化难题。Kotlin Multiplatform 走的是另一条路线共享业务逻辑UI 层各写各的原生代码这反而很接近 Shopify 最终想明白的那个答案“逻辑可以共享体验必须原生”。如果让我给一个决策参照MVP 验证期、团队小、目标双端快速上线优先考虑 RN 或 Flutter产品复杂、强交互、强平台差异化、而且资源充足原生或 KMP 是更稳妥的长期选择。关键在于算清五年总账而不是只盯着第一年的交付速度。5.3 给正在做技术选型的人一个更完整的框架为了不让“算账”停留在嘴上我结合这次事件整理了一个比较常用的决策清单。你可以在自己的项目里直接套用考量维度适合用 RN/Flutter 的团队适合用原生/KMP 的团队团队规模双端合计 10 人以内缺原生专家能养两支独立原生团队或愿意长期培养产品阶段MVP 验证、快速上线抢市场快速试错产品已经稳定需要精细化打磨体验交互复杂度以列表、表单、基础导航为主强动画、AR、相机、地图、硬件交互较多平台差异化需求两端可以接受一致的产品体验两端各自有独立设计语言和交互体系长期维护预算能接受跟着第三方库版本走愿意为稳定性和可控性支付更多开发成本团队经验曲线团队以 JS 开发为主原生基础弱团队有平台归属感愿意做平台深度积累这张表其实没有“正确答案”它的作用是逼你把约束摊开来看。我在实际接触过的团队里很多技术选型争议都不是技术问题而是团队现状和产品愿景之间的错位。选了 RN 但心里一直想着原生体验的过两年一定会难受选了原生但预算根本不够养两支团队的过两年也会被迭代速度拖垮。6. 从 Shopify 事件里学到的三件事个人复盘6.1 技术选型是动态决策不是一锤子买卖很多团队把技术选型当成“结婚领证”觉得一旦选定后面就是一辈子的事。但从 Shopify 这次事件能看到选型更像租房子阶段合适就租团队规模变了、产品定位变了、市场环境变了就要重新评估还值不值得续租。我自己在做技术咨询的时候最推荐的是一年做一次“技术栈体检”重点看团队规模变化、性能指标趋势、框架升级成本这三维是否还在可接受范围内。6.2 用全链路成本而不是“开发速度”来算账“开发速度快”往往是跨平台方案最强的卖点但它只算了第一年的账。一个完整的全链路成本模型至少还要包含后续每一次框架大版本升级的迁移成本、平台新技术被抽象层拖住无法快速使用的机会成本、双端兼容 bug 的排查成本、招资深跨平台开发者的溢价成本。把这些都算进去很多看起来“开发快”的方案三年总成本并不低。这也是 Shopify 用六年时间验证出来的一件事。6.3 团队经验曲线和平台归属感是隐性竞争力这一点比较容易被忽视但我觉得它甚至比技术本身更重要。跨平台方案要求团队既懂 JS 生态又懂原生这种“两头通”的人才培养周期很长流动性也大。而原生团队的经验曲线相对平滑iOS 工程师在 SwiftUI 上积累越深越能做出平台级的精妙体验这种积累也会转化成团队归属感。Shopify 最后跳回原生本质上也是认了这个账与其让百人团队为抽象层打工不如让他们各自在自己的平台上扎下根去。我自己近几年见过不少团队正处在 Shopify 2018 年那个位置预算有限、双端需求强烈、想快速迭代。我的建议从来不是“不要用 RN”而是“先算清未来三年团队规模和产品复杂度的曲线”。技术选型最怕的不是选错而是选了之后每次发现方向不对都想着“再忍忍船到桥头自然直”。这句老话在工程世界里从来都是不成立的。