2025 年 1 月，Shopify 还在庆祝一场持续五年的技术转型。

从 2020 年开始，这家公司陆续把旗下移动应用迁移到 React Native。规模最大的 Shopify 商家端应用，一度有约 600 个页面完成迁移。Shopify 不只是使用者，它还参与了 React Native 新架构的落地，长期赞助 React Native Skia，并开源了 FlashList、Restyle 等颇有影响力的项目。

那篇五周年复盘写得相当乐观：“这场转型取得了相当成功”，“React Native 的未来一片光明”。

但没过多久，Shopify 改变了方向。

9 月 10 日，Shopify 宣布移动应用将重新转向原生开发：iOS 使用 Swift，Android 使用 Kotlin。第一款完成改造的是面向消费者的 Shop。从概念验证到全原生版本正式上架，团队只用了 12 周。接下来轮到更复杂的 Shopify 商家端应用——它有 300 多个页面，还连接着主屏幕和锁屏小组件、Apple Watch、Siri 快捷指令等一系列苹果平台能力。

如果只看结果，这像是又一家大公司放弃了跨平台框架。但事情没有那么简单。

Shopify 离开时，React Native 并不处于低谷。恰恰相反，它刚刚完成一场持续六年的底层重写。长期被诟病的旧 Bridge 架构退出舞台，Fabric、TurboModules、JSI 和 Codegen 全面接管；Hermes V1 默认启用；严格的 TypeScript API 成为公共接口。React Native 还进入了 Linux Foundation 旗下的 React Foundation，治理不再只依赖 Meta。

地基刚换完，生态也基本跟上了。React Native 可能从未像今天这样成熟。

问题因此变得有意思：为什么偏偏在这个时候，Shopify 决定离开？

Shopify 工程总监 Mustafa Ali 给出的解释，不是性能突然恶化，也不是团队无法继续维护，更不是 React Native 项目失败。他说，LLM 改变了 Shopify 在 2020 年做决定时所依赖的一项核心前提。

这个前提其实很朴素：工程师很贵，同一个功能分别用 Swift 和 Kotlin 开发两遍更贵，所以最好只维护一套代码。

如今，代码仍然要写两套，但写代码的人已经不再只有人。

当年那笔账，是怎么算的

先把时间拨回 2020 年。

一家公司要同时开发 iPhone 和 Android 应用，通常需要维护两个工程世界。iOS 团队使用 Swift、UIKit 或 SwiftUI，Android 团队使用 Kotlin、Android View 或 Jetpack Compose。两边的开发工具、系统接口和发布流程都不同。

一个用户看来再普通不过的功能，落到公司内部，可能要走两遍。

例如，Shopify 想给商家应用增加一个商品编辑页面。iOS 工程师先做一版，Android 工程师再做一版；产品需求变更后，两边都要修改；测试人员要分别验证；其中一边出现线上问题，还要单独修复和发版。

真正麻烦的并不是多写几行代码，而是两个版本很容易慢慢走散。

iPhone 已经上线的新功能，安卓可能还在开发；iOS 修复了某个价格计算问题，Android 可能漏改；两个团队对同一项需求理解不同，最后用户看到的页面、交互乃至业务结果都会不一样。

React Native 就是为解决这种重复而生的。

2012 年，Mark Zuckerberg 曾承认，Facebook 过度押注 HTML5 是公司犯下的最大战略错误之一。当时不少企业希望用网页技术同时覆盖不同手机平台，结果在启动速度、滚动和复杂交互上表现不佳。Facebook 随后把 iOS 应用重新改为原生开发，性能问题缓解了，两套开发体系的成本却重新出现。

2013 年的一次内部黑客松上，Facebook 工程师尝试把 React 的开发方式带到手机应用中。开发者仍然用 JavaScript 描述界面和业务逻辑，但屏幕上的文字、列表和滚动区域会映射到手机的原生组件。

2015 年，React Native 正式开源。

它不是简单地在应用里嵌入一个网页，也不是承诺所有代码都能不加修改地运行在任何地方。它真正有吸引力的地方，是让两端共享大部分页面和业务逻辑。商品列表、购物车、登录、订单、表单验证和网络请求可以主要维护一份，只有涉及系统差异的部分才分别处理。

对于 Shopify 这样页面众多、业务变化又很快的公司，这种方案很有吸引力。

因此，Shopify 在 2020 年决定全面转向 React Native。但它没有推倒整个应用从头再来，而是采用“棕地迁移”：保留仍在运行的旧应用，再把页面一个个替换掉。

这是一种谨慎而昂贵的做法。

它的好处是，新页面出了问题，不会把整款应用一起拖下水；缺点是迁移过程很长，新旧技术会在相当长一段时间里共存。团队一边维护旧应用，一边开发新页面，还不能停止正常的产品更新。

Shopify 花了五年才基本完成这场转型。仅商家端应用，就迁移了大约 600 个页面。

以当时的技术条件来看，这笔投入是值得的。大量代码得以在 iOS 和 Android 之间共享，功能也更容易同步上线。所以 Shopify 在五周年复盘中把它称为一次成功的转型，并非事后包装。

但到了 2025 年，那张成本表上的数字变了。

AI 没有消灭两套代码，但压低了第二套代码的价格

Shopify 后来发现，Coding Agent 已经可以完成一些过去必须交给另一组工程师的工作。

它可以阅读已经完成的 iOS 功能，再到 Android 项目中实现对应版本；也可以反过来，根据 Kotlin 代码补出 Swift 实现。一个并不熟悉 Android 的 iOS 工程师，可以借助 Agent 阅读项目、处理编译错误、运行测试，再由熟悉平台的人完成审查。

这里容易产生一种误解：AI 是否已经能把 Swift 一键翻译成 Kotlin？

Shopify 最初也这样试过。

他们把原有的 React Native 代码交给模型，希望模型直接生成原生版本。结果很差。Ali 毫不客气地把那批产物称为“垃圾代码”。即使事先让模型收集资料、整理规范、拆分任务，最后仍会出现大量难以维护、无法发布的代码。

原因并不神秘。一款运行多年的应用，远不只是代码仓库里能看到的那些文件。

为什么这个页面在某种情况下不显示？网络失败以后是否自动重试？用户返回上一级时要不要保留刚才填写的内容？订单处于某个特殊状态时，按钮为什么会消失？这些细节可能藏在测试用例、产品文档、线上日志和工程师的经验里，也可能只是旧代码中的一个特殊判断，从来没有人把原因写下来。

模型可以翻译语法，却未必知道这款应用究竟应该怎样工作。

Shopify 后来不再要求 Agent“把 React Native 翻译成 Swift”，而是先让它弄清旧应用的行为，再使用原生技术重新实现。

这一区别决定了迁移能不能成功。

旧应用里的某段代码也许写得很复杂，其中一部分甚至只是多年迭代留下的历史包袱。新版本没有必要逐行复制它，但必须保证用户进行相同操作时，得到相同的结果。

于是，迁移从代码翻译变成了行为还原。

六个人和十二周

Shopify 先拿 Shop 做实验。

最初只有一名工程师，用一周时间让 Coding Agent 参考现有应用，尽可能重建一个 SwiftUI 版本。那一版还远远达不到上线标准，但它证明了一件事：原生重建不再必然是一个持续数年的项目。

随后，Shopify 组建了一支六人核心团队，负责原生基础设施和主要用户路径。不同功能团队在迁移中途加入，检查自己熟悉的模块，补上模型遗漏的特殊情况。

他们没有让一个 Agent 从头写到尾，而是把迁移做成了一条分工明确的流水线。

有的 Agent 阅读 React Native 源码，有的记录旧应用的运行行为，有的规划原生平台上的实现方式，有的负责写代码，还有的专门检查新旧版本是否一致。

团队还开发了名为 Tardis 的调试工具，把应用运行时的事件、日志和状态交给 Agent。Agent 不仅能读旧代码，还可以实际操作新旧应用，比较同一操作之后的截图、数据和事件。

例如，它可以先在旧应用中打开订单页面，执行取消订单，再到新应用里重复一遍。如果两个版本的按钮状态、接口调用或结果页面不同，差异会被记录下来，Agent 据此继续修改。

在规模更大的商家端迁移中，这套方法又发展成了 Helix。

开发者指定一个页面后，Helix 读取旧代码，把迁移拆成一系列很小的检查点。每一步都要通过测试、视觉比较和两个对抗式代码审查 Agent 的检查，最后还要得到人类批准，才能提交。

这与“让 AI 一口气生成整款应用”几乎是两种相反的思路。

Shopify 的经验不是减少检查，而是因为代码生成太快，反而增加检查。Agent 每次只走一小步，每一步都留下可以核对和回退的结果。

最终，Shop 从概念验证到原生版本正式上架，只用了 12 周。

上一次做大型技术迁移时，Shopify 认为从头重写可能持续数年，所以选择逐页替换。如今，他们反而认为从零开始更快：旧架构可以整个丢掉，不必一边迁移、一边长期维持新旧系统共存。

变化并不是模型突然学会了可靠地生成整款应用，而是 Shopify 建立了一套能够约束模型、观察结果和不断纠错的工程系统。

最慢的环节，已经不是写代码

迁移进行一段时间后，团队遇到了一个过去不太会出现的问题：Agent 写代码太快，模拟器跟不上。

一次代码修改可能只需要几秒钟，但要验证它，往往需要重新编译应用、启动模拟器、登录测试账号、进入指定页面，再执行一连串操作。整个过程可能花几分钟。

当修改速度从几小时缩短到几秒，过去不起眼的构建和测试时间就成了主要瓶颈。

Shopify 开始把业务逻辑与界面拆开。价格计算、订单状态处理和数据转换等逻辑，不再必须打开手机模拟器才能运行，而是可以通过命令行直接调用。

原来需要几分钟才能得到的结果，有些被缩短到了几毫秒。

这可能比“12 周重写一款应用”更值得注意。

在传统软件开发中，工程师大部分时间花在实现功能上；当 Agent 可以快速生成实现以后，开发速度越来越取决于团队能否快速回答一个问题：

它写得对不对？

如果测试不完整、业务规则没有记录、应用无法被自动操作，那么 Agent 生成得越快，制造出来的错误也可能越多。

Shopify 真正投入建设的，因而不只是代码生成工具，而是一套验证机器：旧应用的行为可以被记录，新应用可以被操作，结果可以被比较，每次改动都能接受自动审查。

AI 在这里没有取代软件工程。它反而迫使软件工程把过去依靠经验完成的检查，变成更明确、更可执行的流程。

React Native 偏偏在这时成熟了

如果 Shopify 是因为 React Native 性能越来越差而离开，这个故事反而容易理解。麻烦在于，过去几年恰恰是 React Native 集中偿还技术债的阶段。

早期 React Native 最受诟病的部分，是 JavaScript 与原生系统之间那座被称为 Bridge 的“桥”。

开发者用 JavaScript 编写页面和业务逻辑，真正负责显示界面、调用相机或处理手势的，则是 iOS 和 Android 的原生系统。两边要交换信息，数据需要经过序列化、排队和跨线程传递。

普通业务页面未必能明显感受到这层开销。可是一旦遇到高频动画、快速滚动、复杂手势，或者需要频繁传输大量数据，这座桥就可能堵车。

用户不会知道什么叫 Bridge，只会觉得列表不够顺滑、动画偶尔掉帧，或者页面上的浮层总是慢半拍。

2018 年，Facebook 公布了 React Native 的底层重写计划。此后的六年里，团队几乎把框架的核心部件换了一遍。

JSI 改变了 JavaScript 访问原生对象的方式。过去，两边沟通往往要先把数据“打包”，通过 Bridge 传输，再到另一端“拆包”；有了 JSI，JavaScript 可以更直接地调用 C++ 和原生对象，也能进行同步调用。

TurboModules 重做了原生模块系统。应用不必在启动时把所有原生能力一次加载完，而是可以等真正用到时再加载。

Fabric 则替换了旧渲染器。它负责把 React 中描述的组件真正放到手机屏幕上。新渲染器支持同步布局测量，也能承接 React 18 的并发渲染、Transitions 和 Suspense 等能力。

同步布局测量听起来很底层，实际影响却很直观。比如一个气泡提示需要紧挨着按钮出现，程序必须先知道按钮在屏幕上的准确位置。旧架构下，测量和显示之间可能隔着异步通信，气泡先出现在错误的位置，再突然跳回去。新架构可以在更合适的时机同步取得布局信息，减少这种视觉抖动。

Codegen 则根据类型定义自动生成 JavaScript 与原生模块之间的连接代码。过去需要工程师手工维护的接口，现在可以由工具生成，并在编译阶段发现一部分类型错误。

这项重写最难的地方，不只是设计一套新架构，而是在海量生产应用仍然运行时完成替换。

React Native 不能宣布旧版本作废，再要求全世界从头升级。Meta 自己有大量产品依赖它，社区中还有数以百计的组件库。相机、地图、动画、支付和推送等常用功能，都需要第三方维护者跟进新架构。

因此，新旧架构并行了很长时间。框架团队要保证已有应用继续运行，还要让社区逐步迁移。等新架构正式发布时，已有超过 850 个社区库完成适配。

2024 年 10 月，React Native 0.76 默认启用新架构。到 2025 年 10 月发布的 0.82，React Native 已经完全运行在新架构上，开发者也不能再退回旧架构。2026 年 2 月，Hermes V1 默认启用。Hermes 是为 React Native 优化的 JavaScript 引擎，负责执行应用中的 JavaScript 代码。

同月，React 与 React Native 进入 Linux Foundation 旗下的 React Foundation。华为成为首批白金成员之一，希望推动 OpenHarmony 与 React 技术之间的互操作。

State of React Native 2025 调查显示，新架构采用率达到 80%，88% 的受访开发者认为框架正在朝着正确方向发展。到 2026 年 6 月，React Native 的 npm 周下载量一度达到约 1053 万次。

无论从架构、生态还是使用规模看，这都不像一个即将无人问津的项目。

也正因如此，Shopify 的转向才显得格外刺眼：React Native 花了六年解决自己最棘手的问题，等到地基终于换完，外部世界衡量它的标准却变了。

框架团队解决的是“跨平台怎样运行得更好”，AI 带来的问题则是：“如果分别开发两个原生版本已经没有以前那么贵，我们还需不需要这个跨平台层？”

前一个问题属于技术，后一个问题属于经济。

技术上的进步，并不能自动回答经济上的新问题。

原生版本的数字，应该怎样看

Shopify 公布了 Shop 原生版本与 React Native 版本的一组对比数据。原生版本在启动速度、应用体积、响应表现和资源占用等指标上都有改善。

这组数字很容易被解读为“Swift 终于证明自己比 React Native 快”。Shopify 自己却没有下这么绝对的结论。

原因是，这并不是一场严格控制变量的实验。

团队在重建应用时，也顺便清理了旧产品。部分功能被精简，多年累积的历史代码被删除，页面结构和数据流程重新整理。一个轻装上阵的新应用，与一个经过多年迭代、背负大量兼容逻辑的旧应用相比，本来就可能表现得更好。

如果 Shopify 使用 React Native 从零重建一个同样精简的版本，差距究竟还剩多少，现有数据并不能回答。

但对 Shopify 来说，这并不妨碍决策。

企业选择技术栈，并不是为了证明某种语言在实验室里更快，而是要判断一整套系统是否划算。重写之后，Shop 的原生版本更轻，也更方便直接使用平台能力；与此同时，Coding Agent 又把重写周期压到了可以接受的范围。两件事放在一起，已经足够让账本倾斜。

React Native 过去的优势，也从来不是每一项性能都超过原生。它更像是用一层框架换取更大范围的代码共享。

只要共享代码省下的成本，足以覆盖框架层带来的调试、适配和升级负担，这笔交换就值得。

现在，Shopify 认为天平变了。

下一场迁移更难，也更有说服力

Shop 只用了 12 周，但它并不是 Shopify 手中最复杂的移动产品。真正考验这套方法的，是接下来的商家端应用。

这款应用有 300 多个页面。商家用它处理订单、管理商品、查看经营数据，也通过它接触大量苹果系统能力。它不仅有普通手机页面，还包括主屏幕与锁屏小组件、Apple Watch 应用和 Siri 快捷指令。

这类功能对跨平台框架一直不算友好。

并不是 React Native 完全做不了，而是越靠近操作系统，框架能够统一处理的部分越少。开发者最后仍要进入 Xcode，编写 Swift 或 Objective-C；到了 Android，又要使用 Kotlin 或 Java 完成另一套实现。

此时，一项功能可能同时横跨 React Native、第三方库和原生模块。出了问题，工程师需要先判断故障发生在哪一层：是 JavaScript 状态错误，是框架渲染异常，是原生模块接口不一致，还是操作系统升级改变了行为。

跨平台框架原本用来减少复杂度，在某些深度依赖系统能力的应用中，也可能成为复杂度的一部分。

直接使用 Swift 开发，可以在苹果发布新 API 后立即接入，不必等待 React Native 或社区库完成封装。Kotlin 版本也可以按 Android 自己的方式处理权限、后台任务和设备差异。

从前，平台能力再重要，公司也要考虑两支团队的成本。如今，Shopify 希望让 Agent 承担两个平台之间的大量重复实现，于是原生方案的吸引力重新上升。

商家端应用计划在 2026 年内发布原生版本。如果这场迁移也能在较短时间内完成，它会比 Shop 更有说服力。因为这一次面对的不只是普通页面，而是一套规模更大、历史更久、与操作系统结合更深的生产应用。

当然，它也可能暴露 Shop 实验中没有遇到的问题。页面从几十个增加到几百个以后，Agent 生成的代码能否长期保持统一？两个原生版本迭代几年之后会不会重新分叉？今天依靠严格检查控制住的质量，到了日常高速开发中还能否维持？

12 周证明了重建可以很快，却还没有证明维护十年同样便宜。

这部分答案，只能由时间给出。

Shopify 的经验，普通团队很难原样复制

“六个人，12 周，从零重写一款应用”很适合成为标题，也很容易让管理者产生冲动：既然 Shopify 能做到，我们是不是也能把旧系统扔给 AI，下个季度交付新版本？

但仔细看 Shopify 的过程，会发现真正稀缺的并不是那六名工程师。

他们背后还有完整的产品资料、成熟的自动化测试、旧应用的运行数据，以及能够开发 Pi 扩展、Tardis 和 Helix 的基础设施团队。功能团队也会在迁移过程中加入，对自己熟悉的模块做最后确认。

换句话说，参与重建的远不只是六个人。六人是核心团队，整个组织积累的知识、工具和审查能力都在为他们服务。

普通团队往往缺少这些条件。

不少旧应用连基本测试都不完整，关键业务规则只存在于几位老工程师的脑中；有些页面为什么这样设计，团队里已经没人说得清；线上出错后靠人工查日志，界面差异也只能由测试人员一页页检查。

这样的项目交给 Agent，最大的风险不是它写得慢，而是没有人知道它究竟写对了没有。

Shopify 的经验并不是“买一个 AI 编程工具，就能用六个人替代几年工作”。更接近事实的说法是：当一家公司有能力把旧系统的行为暴露出来，把任务拆成小步骤，并为每一步建立自动验证时，Agent 可以大幅提高重写速度。

模型只占其中一部分。

剩下的部分依然是传统工程能力，只不过过去很多依赖人工完成的事情，现在需要被改造成机器可以读取、执行和判断的流程。

这也是为什么直接把代码仓库交给模型会失败，而经过 Tardis、Helix 和多轮审查的迁移能够落地。

React Native 会因此失去价值吗

Shopify 是一个重要用户，却不是整个市场。

Meta、Microsoft、Expo 仍在投入 React Native，使用者名单也依然很长。每周超过千万次的 npm 下载，说明大量新旧项目仍然依赖它。

更重要的是，不是每家公司都像 Shopify 一样，需要为大量系统级能力做深度适配。

对许多应用来说，主要工作仍然是展示内容、填写表单、调用接口和管理业务状态。它们不需要连接 Apple Watch，也不会频繁调用复杂的相机、蓝牙或后台能力。iOS 与 Android 上的产品形态几乎相同，团队也已经熟悉 React 和 TypeScript。

在这些项目中，共享代码仍然是非常实在的优势。

一家十几人的创业公司，要同时招到成熟的 Swift 和 Kotlin 工程师并不容易。使用 React Native，可以让现有 Web 或 React 开发者更快进入移动端，也能在产品尚未验证时尽快推出两个平台版本。

Agent 可以协助写原生代码，但它无法替公司承担上线后的责任。代码出了安全问题，应用崩溃，或者支付流程发生错误，最后签字负责的仍然是人。如果团队里根本没有人理解 iOS 和 Android，生成两套看不懂的代码未必比维护一套 React Native 更轻松。

React Native 还保留着另一项容易被忽视的优势：一套代码不只减少首次开发量，也让后续修改天然同步。

如果税费规则改变，共享业务逻辑只需要修改一次。两套原生代码即使可以由 Agent 快速更新，也仍然需要分别生成、测试和发布。只要两个实现独立存在，就存在逐渐分叉的可能。

AI 降低了重复实现的成本，却没有让一致性问题消失。

因此，Shopify 的离开并不能推出“所有应用都该回归原生”。它只说明过去那个近乎自动成立的判断——原生一定贵得多——已经需要重新验证。

不同团队最后可能得到完全不同的答案。

对一款主要由列表和表单组成、要求快速上线的应用，React Native 仍然可能更合适。对一款追求极致交互、深度调用系统能力、又拥有完善 Agent 基础设施的应用，Swift 和 Kotlin 可能重新占优。

框架没有统一的胜负，只有具体的账。

Airbnb 的离开，与 Shopify 并不是同一个故事

React Native 的历史上，并不是第一次有知名公司退出。

Airbnb 曾经大规模采用 React Native，后来又决定回归原生。那次退出经常被用作“跨平台不可行”的证据，但 Airbnb 当时给出的原因更复杂：团队要同时维护 React Native 和原生基础设施，跨团队协作困难，部分工程师需要掌握三套环境，而公司已有强大的 iOS 与 Android 团队。

Shopify 这一次看起来相似，背景却不同。

Airbnb 离开时，React Native 本身仍较年轻，新架构也远未完成。它面对的是框架成熟度、组织结构和维护复杂度的问题。

Shopify 离开时，React Native 已经更成熟。Shopify 也不是因为迁移失败才退出——它明确承认过去五年的转型取得了成功。

这使得 Shopify 的决定更值得注意。

它不是在说“我们当年选错了”，而是在说“当年支持这个决定的条件变了”。

技术选型通常就是这样。一个决定是否正确，不能脱离做决定时的环境。2020 年的 Shopify 选择 React Native，可能是当时更好的答案；几年后，当 Agent 能力、平台需求和组织成本都发生变化，选择 Swift 和 Kotlin 也可能是合理答案。

前后不同，并不必然意味着其中一次犯了错误。

一次技术选择，过去会长进公司身体里

长期以来，企业选择一种语言或框架，远远不只是确定代码文件使用什么后缀。

一旦选择 React Native，公司会招聘熟悉 React 和 TypeScript 的工程师，围绕 Metro、Hermes 和原生模块建立构建流程；测试工具、发布系统、代码规范和团队分工也会随之调整。

使用时间越长，这套技术就越深入组织。

几年后，即使发现另一种方案更适合，迁移也很难进行。旧系统仍然要发布新功能，新系统又没有完全准备好，两边长期并行，成本可能比继续忍受原技术的问题更高。

所以，很多公司不是认为现有技术最好，而是迁移太贵。

技术栈一旦选定，常常像一条越走越难回头的路。企业在最初选型时反复比较，正因为一次决定可能影响未来五年甚至十年。

Shopify 当年迁移到 React Native，也采用了逐页替换的棕地策略。因为在传统成本模型中，把一款成熟应用从头重写，几乎等同于主动承担数年的双线开发。

Agent 首先改变的，可能正是这种不可撤回性。

如果旧系统能够被自动阅读，行为能够被记录，代码能够快速生成，测试能够自动运行，那么重写不再必然是持续数年的大型工程。公司不需要等到现有技术彻底无法维护，才被迫启动迁移，而可以更频繁地重新计算。

框架、语言和数据库不会因此变得不重要。选错技术依然会付出代价。但这种代价可能不再像过去那样大到足以决定一家公司的长期命运。

技术选型会更像一项可以撤回的工程决定，而不是只能押注一次的路线选择。

这对框架行业未必是好消息。

过去，一个框架只要进入大型企业，就能依靠巨大的迁移成本获得多年稳定使用。今后，用户是否留下，不只取决于框架够不够好，也取决于离开它是否已经变得足够便宜。

Shopify 的决定正发生在 React Native 最成熟的时候，说明仅仅把框架做好，可能已经不足以保证用户继续留下。

以后需要共享的，也许不再是代码

跨平台开发过去追求的是同一份源代码。

iOS 和 Android 尽量共用组件、状态管理和业务逻辑，只在必要时写少量平台代码。这样做的价值，是避免两套实现产生重复和偏差。

Shopify 的做法却显示出另一种可能：两个平台可以拥有各自的原生代码，但共享同一套规格、测试和审查标准。

以退款功能为例，真正需要长期保持一致的，不一定是 Swift 和 Kotlin 的代码结构，而是这些规则：

什么状态下允许退款，退款金额怎样计算，接口失败后是否重试，用户会看到什么提示，操作完成后订单进入什么状态。

如果这些规则已经写成明确的规格和可执行测试，Agent 就可以分别生成两个平台的实现，再用同样的标准验证。

共享层从代码上移到了知识。

这听上去只是表达方式不同，实际会改变很多软件架构的基本假设。

过去，人们担心两套代码会逐渐分叉，所以把代码放在同一个跨平台框架里。未来，如果 Agent 能持续读取同一份规格，执行同一组测试，并自动修复两个版本的差异，那么代码本身是否相同，可能不再是最重要的问题。

甚至 Web、iOS、Android 和桌面应用，也可以根据各自平台选择最合适的技术。它们共享的是产品行为和业务规则，不必强行共享每一行实现。

这条路还远没有被证明。

自然语言规格可能含糊，测试也不可能覆盖所有行为。两套独立代码运行几年后是否会失控，仍然是现实风险。但 Shopify 已经把这个原本停留在想象中的方向，推进到了一款正式上架的产品里。

“代码只写一遍”并没有消失，只是它可能不再是实现一致性的唯一办法。

代码越来越便宜，知识反而越来越贵

Shopify 第一次让模型直接改写旧应用时，得到大量无法发布的代码。这件事提醒人们：大型软件真正难以复制的部分，未必是源代码本身。

以电商系统为例，代码背后藏着大量业务知识：

库存应该在什么时候锁定，优惠券能否叠加，订单取消后怎样退回额度，跨境交易如何计算税费，支付成功但回调失败时怎样补偿，不同身份的商家可以看见哪些数据。

这些规则可能经过多年事故和用户反馈才逐渐形成。

代码只是它们当前的一种写法。

如果规则没有文档，没有测试，甚至没人能解释，AI 即使把旧代码逐行翻译成新语言，也可能复制错误、遗漏例外，或者在“优化”时删掉一段看似多余、其实用于处理真实事故的逻辑。

相反，如果业务知识已经被整理成规格，关键行为有完整测试，系统运行过程也可以被观察，那么代码就更容易替换。

Shopify 为 Agent 开发 Tardis 和 Helix，本质上是在把原本散落于代码、运行状态和工程师经验中的知识，变成机器能够使用的材料。

这也许会改变企业对软件资产的理解。

过去，人们常用代码行数描述一个系统的规模。一百万行代码意味着多年投入，也意味着很高的替换成本。现在，代码行数仍然代表复杂度，却不一定继续等同于不可复制的价值。

真正难以替代的，可能是：

企业对业务的理解，规则形成的历史原因，对异常情况的处理经验，能够证明系统正确的测试，对真实运行状态的观测能力。

AI 可以在几秒钟内生成几百行代码，却不能自动补回从未被记录的业务知识。

当实现开始变便宜，准确描述“应该实现什么”就会变得更贵。

React Native 的黄金时代结束了吗

说 React Native 的黄金时代结束，多少带有标题需要的锋利。

一个每周下载量仍然超过千万、由多家大公司和活跃社区维护的框架，不会因为 Shopify 的离开突然退出历史。新架构刚刚完成，很多团队甚至才开始真正享受这次重写带来的改善。

但如果把“黄金时代”理解为一种默认观念，那么它确实开始松动。

过去十年，跨平台框架最有力的推销方式很简单：同一个功能为什么要开发两遍？只写一套代码，显然更省人，也更容易保持一致。

这个说法建立在“第二套实现主要由另一批人手工完成”之上。

现在，Agent 可以阅读第一套实现，生成第二套实现，处理编译错误，运行测试并参与审查。人仍然不可缺少，但人所承担的工作开始从逐行实现，转向定义、验证和决策。

两套代码没有变成一套，第二套代码的价格却下降了。

当节省代码不再等于按比例节省人力，React Native 就必须依靠更多东西证明价值：开发体验、生态质量、升级稳定性、运行性能，以及它是否真的比“原生加 Agent”更容易维护。

对 React Native 来说，这不是末日，却是一种新的竞争。

它过去主要与纯原生团队竞争，未来还要面对被 AI 大幅增强的原生团队。

写在最后

Shopify 不是在 React Native 最糟糕的时候离开，而是在它完成六年重写、技术上最成熟的时候离开。

这个时间点让整件事超出了一次普通迁移。

React Native 解决了 Bridge、渲染器、原生模块和类型安全等长期问题，却无法控制另一条曲线：生成代码的成本正在快速下降。

2020 年，Shopify 选择 React Native，是因为同时维护 Swift 和 Kotlin 意味着大量重复人力。五年后，Coding Agent 已经能够参考一个平台完成另一个平台的大量实现，原来的核心前提不再稳固。

Shopify 因此重新算了一遍账。

它没有证明 React Native 是错误，也没有证明所有公司都应该回到原生。它只是展示了一个越来越可能发生的未来：当迁移成本下降，曾经被认为不可逆的技术决定，也可以重新打开。

以后选择框架，企业也许不必再问“未来十年我们能不能一直用它”，而会更多地问：“在接下来的阶段，它是不是成本最低、最容易验证的方案？”

答案变了，就换。

真正需要长期保存的，也不一定是哪一种语言写成的代码，而是产品如何运行、业务规则为何如此，以及怎样证明新的实现没有偏离。

React Native 依然成熟，依然有用，也依然会拥有大量用户。

只是它最熟悉的那套时代逻辑正在发生变化。

过去，人太贵，所以代码最好只写一遍。

现在，代码可以重新生成，技术栈可以重新选择，真正昂贵的东西逐渐变成了另一种：没人写下来的知识，以及无法自动确认的正确性。

React Native 的黄金时代未必在某一天突然结束。

更可能的情况是，当它终于换完地基，抬头才发现，所有人已经开始用另一种方式计算建造一座房子的价格。

---

参考资料

• Shopify Engineering：Five Years of React Native at Shopify
  https://shopify.engineering/five-years-of-react-native-at-shopify

• Shopify Engineering：Back to Native
  https://shopify.engineering/back-to-native

• Shopify Engineering：Shop App Migration
  https://shopify.engineering/shop-app-migration

• React Native：The New Architecture Is Here
  https://reactnative.dev/blog/2024/10/23/the-new-architecture-is-here