开源于 2015 年的 React Native，刚刚走完一场历时六年的底层重写。新架构全面接管，旧架构被冻结，Hermes V1 默认启用，严格 TypeScript API 成为默认公共接口。从框架自身的技术演进看，这几乎是 React Native 历史上最成熟的时刻。

就在这个节点，Shopify 宣布离开。

它投入数年、把旗下应用陆续迁上 React Native，参与新架构落地，还长期赞助 React Native Skia，开源了 FlashList、Restyle 等高影响力项目。2025 年 1 月，Shopify 还在公开表示 React Native 前景光明，公司会继续投入。

但就是前几天（9 月 10 日），它宣布重返原生开发，旗下移动应用将全面转向 Swift 和 Kotlin，并大量依靠 Agent 完成重写。消费者应用 Shop 从概念验证到正式发布全原生版本，只用了 12 周。接下来是拥有 300 多个页面、深度依赖 iOS 平台能力的商家端应用。

一个刚把底层重写做完的框架，一个才宣布要继续投入的大用户，此刻却走向了相反方向。

这已经超出一次普通的框架迁移：React Native 的黄金时代，建立在“人太贵，所以代码最好只写一遍”这个前提上；当 Agent 开始承担实现，这个前提正在失效。原生开发的价格被重新标定，而 React Native 的黄金时代，恰好在它最成熟的那一年，撞上了 AI 时代。

Shopify 的离开：账本换了，答案就换了 

2020 年，Shopify 做出了一个在开发者圈引起广泛共鸣的决定：采用 React Native，只编写一套移动端代码，不再用 Swift 和 Kotlin 分别重复实现每项功能。

五年后，Shopify 旗下移动应用已全部完成迁移。仅规模最大的 Shopify 商家端应用，就有约 600 个页面被迁移至 React Native。2025 年 1 月，Shopify 在复盘文章中写道：“这场转型取得了相当成功”，“React Native 的未来一片光明”。

但现在，Shopify 工程总监 Mustafa Ali 又在官方博客中坦言：“LLM 改变了我们在 2020 年做出这一决定时所依据的一项核心前提。”

2025 年底，Shopify 发现 Coding Agent 已经可以做到几件事。参考 iOS 版本，在 Android 上实现相同功能，反过来也同样可行。不熟悉某个平台的工程师，能在 Agent 协助下高效参与开发。共享的 specifications、测试和审查检查点，大幅降低了维持两个平台功能一致性的成本。

原生开发依然意味着两套代码，这项成本没有消失。真正变化的是，Agent 已经能承担足够多的实现、翻译、测试和审查工作，使得“两套代码等于两倍人力”的等式不再成立。

Shopify 因此从第一性原理重新评估了移动技术栈。最终的答案，是回到 Swift 和 Kotlin。

当初迁移到 React Native 时，他们采用的是渐进式“棕地迁移”：保留现有应用，逐个页面替换。因为从头重写可能持续数年，期间还会拖慢新功能发布。但现在，有了 Coding Agent，Shopify 选择直接进行“绿地重建”：摆脱历史包袱，一切从零开始。

第一款被选中的应用是 Shop。

12 周，6 个人，从零重写 Shop 

Shopify 最初的想法很简单：把现有 React Native 代码库交给 LLM，让它直接重写成原生代码。结果并不理想。Ali 将模型直接生成的内容称为“垃圾代码”。

并且即使你要求它预先收集尽可能多的信息，将其冻结到规范和任务文件中，然后再进行实现，最终也会产生大量难以维护且无法发布的代码。

Shop 的实际迁移由一次小规模实验开始。一名工程师用一周时间，让 Coding Agent 参考现有应用，尽可能多地重建 SwiftUI 版本。成果还不能投入生产，却已经证明原生重建可行。随后，Shopify 组建了一支 6 人核心团队，负责原生基础设施和主要用户路径，各功能团队在迁移中途加入，验证模块并补齐边缘场景。

为了控制代码质量，Shopify 将一套可复用的迁移工作流做成了 Pi Coding Agent 的扩展。不同的子 Agent 分别检查 React Native 源码、记录应用行为、制定平台计划、完成实现并审查功能一致性。

团队还开发了一个调试工具 Tardis，把应用运行时的事件、日志和状态提供给 Agent，让它能够比较新旧版本的截图、分析事件和数据行为。

在随后规模更大的 Shopify 商家端迁移中，这套思路又被发展成了 Helix。开发者先指定一个页面，Helix 读取原有代码，再把迁移拆成一系列可以在几分钟内审核的小型检查点。每个检查点都必须通过测试、与旧应用完成视觉对比、经受两个对抗式代码审查 Agent 的检查，并获得人类批准，才能提交并进入下一步。

Shopify 还发现，限制 Agent 速度的环节已经从写代码转向验证。Agent 几秒钟就能完成修改，在移动模拟器中构建、操作和检查结果却要花费几分钟。团队因此开始将业务逻辑与 UI 解耦，使其能够在桌面端无界面运行，再通过 CLI 开放给 Agent。部分原本依赖模拟器、耗时数分钟的反馈循环，由此被缩短到几毫秒。

最终，从概念验证到全原生版本正式上架，Shop 只用了 12 周。上一次进行大型技术迁移时，Shopify 认为从头重写应用可能耗时数年；Coding Agent 让原本难以承担的绿地重建，变成了一条更快的路径。

Shopify 公布了原生版本与 React Native 版本的对比数据：

Shopify 也承认，这些发布中包含了一些产品精简，所以改善不能全部归功于去掉框架。但数据指向的方向是清楚的：当跨平台框架省下的钱不再足以覆盖它引入的复杂度，原生开发的优势就会重新占据上风。

接下来是 Shopify 商家端应用，拥有 300 多个页面、主屏幕与锁屏小组件、Apple Watch 应用、Siri 快捷指令，计划在 2026 年内发布原生版本。

React Native 没有突然变差，只是原生开发的价格被 AI 重新标定了。

十年投入，React Native刚走到最成熟的阶段 

React Native 的故事，起点是 Facebook 的一次失败。

2012 年，Mark Zuckerberg 公开承认，过度押注 HTML5 是 Facebook 犯下的最大战略错误之一。用 Web 技术覆盖移动端的尝试，在启动速度、滚动体验和交互性能上都不理想。Facebook 随后重写 iOS 应用，将核心移动应用转向原生实现。

但全面原生带来了另一项代价：iOS 和 Android 使用两套语言、两套工具链，同一个功能往往需要开发两遍。React Native 就诞生在这组矛盾中。

2013 年，它最初只是 Facebook 内部黑客松上的实验项目，团队尝试把 React 的声明式组件模型带到移动端：开发者用 JavaScript 和 React 描述界面与应用逻辑，屏幕上呈现的 View、Text、ScrollView 等元素仍然映射到原生组件。其理念被概括为“Learn once, write anywhere”——学习一次，随处编写。

2015 年，React Native 正式开源。此后，它从 Facebook 的内部方案逐渐成长为完整生态，成为跨平台移动开发最受关注的框架之一。Instagram、Airbnb、Walmart、Bloomberg、Discord 等公司陆续采用，Microsoft 和 Samsung 参与开发，Expo 则围绕它建立起项目创建、构建、更新和原生模块等工具。

到 2025 年，React Native 已拥有超过 3000 名 GitHub 贡献者，2026 年 6 月，React Native 的 npm 周下载量进一步突破 1000 万次。

React Native npm 下载在 2026 年 6 月达到每周下载量峰值，约为 1053 万次。

React Native 后来的成熟，建立在一场持续六年的底层重写之上。

2018 年，Facebook 公布了 React Native 的底层重写计划。旧架构的核心是异步 Bridge：JavaScript 与原生层之间的数据需要经过序列化、排队和跨线程传递。在频繁更新或传输大型对象时，这座桥很容易成为瓶颈，也让应用难以稳定实现 60 FPS 以上的流畅体验。

新架构的目标，是拆掉这座桥。JSI 让 JavaScript 可以直接访问 C++ 和原生对象，支持同步调用，省去 Bridge 带来的序列化与排队过程。围绕这个核心，TurboModules 重写原生模块系统，Fabric 重写渲染器，Codegen 自动生成类型安全的绑定代码。

这已经超出一次普通的内部重构，接近在飞行中更换发动机。六年里，React Native 既要保证旧架构和大量生产应用稳定运行，又要并行开发新架构，还要推动第三方生态完成迁移。到新架构正式发布时，已有超过 850 多个社区库完成适配。

2024 年 10 月，React Native 0.76 默认启用新架构。同步布局测量解决了 tooltip 等组件的位置跳动，并发渲染让 React 18 的 Transitions 和 Suspense 真正在移动端落地，自动批处理则减少了中间状态的重复渲染。这些能力已经超出性能优化的范畴，其中一些在旧架构上根本无法实现。

到 2025 年 10 月，React Native 0.82 完全运行在新架构上，并关闭了退回旧架构的选项。2026 年 2 月，Hermes V1 默认启用；同月，React 与 React Native 正式进入 Linux Foundation 旗下的 React Foundation。华为成为首批白金成员之一，希望推动 OpenHarmony 与 React 技术之间的互操作。

State of React Native 2025 调查显示，新架构采用率达到 80%，88% 的开发者认为框架正朝着正确方向前进。从框架自身的技术演进看，这几乎是 React Native 历史上最成熟的时刻。地基换完了，社区跟上了，治理也走向中立。但时代变了。

写在最后 

Shopify 不是孤例。

真正值得注意的，是迁移成本下降之后，技术选型这件事本身的性质变了。过去，语言、框架、数据库的选择一旦做出，就会长进组织结构里——招聘按它来，测试体系按它来，部署方式按它来，时间越久越像一条公司命运线。所以选型要反复验证，迁移要以“年”为单位计算。

现在，当重写从数年压缩到数周，这条命运线开始变得可以撤回。框架选型不再是一次性押注，而更像一个随时可以重新评估的工程决策。React Native 官网列出的“谁在使用”列表依然很长，Meta、Microsoft、Expo 也还在继续投入，框架本身没有突然变差。变的是它赖以为生的那个前提——“人太贵，所以代码最好只写一遍”——正在被 AI Agent 一 点点 拆掉。

关于这场变化更完整的图景，我在上一篇文章《AI 确实可以用任何手段、写任何东西，但你得是个“中年老登”》中做过梳理：从 TiDB 联合创始人黄东旭三个月做出 100 万行代码的 db9，到 Thoughtworks 用 LLM 反向还原没有源码的企业系统，再到徐昊提出的“软件不是产品，软件中的知识才重要”。技术栈、框架、语言，正在从“公司命运线”变成“可撤回的工程决策”。

如果这篇文章让你重新思考了技术选型的逻辑，那篇值得一并读一读。

本文来自微信公众号 “InfoQ”（ID：infoqchina），作者：Tina