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协助下高效参与开发。共享的规格说明、测试和审查检查点，大幅降低了维持两个平台功能一致性的成本。

原生开发依然意味着两套代码，这项成本没有消失。真正变化的是，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，36氪经授权发布。