“倒反天罡！押注 React Native 6 年后，Shopify 又回到了原生开发”——我看到这条消息时的第一反应，和评论区里大多数人一样：暗叫一声“这也能回头？”毕竟当年 Shopify 高调拥抱 React Native 的时候，可是被很多人当成跨平台方向的标杆案例来引用的。如今说走就走，等于当着全行业的面承认：我们当年那套跨平台路线，走到今天不划算了。
我做了十来年移动端技术方案选型，看到这条消息倒不觉得震惊，反而觉得这是一次特别好的“群体复盘样本”。这篇不打算写“RN 已死”或者“原生永远滴神”这类情绪化的东西，而是想把 Shopify 这六年到底经历了什么、官方公告里哪些话是客套、哪些话是真心、技术账和经济账分别怎么算，完整拆一遍。适合这三类朋友阅读：正在纠结 React Native、Flutter、Kotlin Multiplatform 和原生怎么选的技术负责人，正在维护 RN 项目但被性能和兼容性折腾得够呛的开发者，以及只想吃瓜但想从案例里读出点门道的人。
下面我会先把 Shopify 的六年路线串起来，再从技术原理层面复盘它踩过的坑，最后聊聊这次“倒反天罡”对整个跨平台技术栈格局的影响。
1. 先复盘一下：Shopify 这 6 年走了一条什么路
1.1 2018 年的选择：为什么一家电商巨头会押注 React Native
2018 年前后，移动电商的竞争已经白热化。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、JSI（JavaScript Interface），每一次演进都意味着存量项目要跟着迁移、适配、重构。这些成本不会消失，它们只是被记在了跨平台选型的长期账单里，等到某个临界点一次性爆发。
2. 宣布回归原生：不是拍脑袋，是账算不过来了
2.1 官方表态里的关键信息，翻译成大白话是什么
Shopify 工程团队在官方博客里宣布：未来的移动端开发将转向原生技术栈，iOS 用 SwiftUI，Android 用 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”，而是“先算清未来三年团队规模和产品复杂度的曲线”。技术选型最怕的不是选错，而是选了之后，每次发现方向不对都想着“再忍忍，船到桥头自然直”。这句老话在工程世界里，从来都是不成立的。
