最近 Shopify 宣布公司已经把旗下 App 从 React Native 转回 Swift 和 Kotlin ，就像六年前 Shopify 那时候也高调宣布 “React Native is the Future of Mobile at Shopify” 一样，那时候 Shopify Mobile、Shop、Point of Sale、Inbox 之类的核心应用都迁移到 React Native，甚至公司还深度参与 React Native 生态，做出了 FlashList、Restyle、React Native Skia 等项目。

特别是 FlashList 和 React Native Skia ，这两个 RN 开发者应该都不陌生，去年的时候 Shopify 还发了《Five years of React Native at Shopify》总结这五年实践：

应用页面 P75 加载时间低于 500ms，Crash-free Sessions 超过 99.9%，iOS 和 Android 功能一致性基本不再成为问题。

去年底 Shopify Mobile 和 POS 才刚完成了 React Native New Architecture 的大规模迁移，然后这菜不到一年，突然就又开始回到 Swift/Kotlin。

而且按照 Shopify 的说法，这次迁移不是 React Native 的性能有问题，主要是它们整了一套架构叫 Helix，因为 Shopify 一开始试过把 React Native Repo 扔给 Claude、Codex 一类 Coding Agent，然后来一句：

把这个 App 改写成 Swift 和 Kotlin。

但是拿到的效果差的一批，就算先让模型分析代码、生成 Spec、拆任务，再开始实现，最后还是做出来一堆没办法维护和发布的代码。

所以 Shopify 做了一套叫 Helix 的系统，主要面向 checkpoint，就是开发者指定一个页面以后，Helix 先读取 React Native 实现，然后把迁移工作拆成很多可以在几分钟内 Review 完的小片段，这里每一个 checkpoint 都必须完成几件事：

• 实现对应功能

• 自动测试证明行为正确

• 和正在运行的旧 App 做视觉比较

• 接受两轮 adversarial code review

• 开发者正式 Review 后才能 Commit

• 然后继续下一个 checkpoint

也就是其实这也是一个 Flow 系统，这里每次 Review 得到的反馈后，还会进入后续执行过程，所以迁移越往后，系统整套逐渐可以承担更多工作。

实际上到了后续开发业务也能用，不然你真的以为，同一个需求直接让 AI 写两次就完事了？实际上如果你没有一套优秀的 Harness 环境， AI 写两次只会给你多一倍 Bug 量。

Shopify 针对自己业务设计的这套 Helix，就是为了模型第一次生成的代码质量不稳定，而且也不要求它能一次写对，Shopify 把工程系统设计成：

错误可以出现，但是必须能尽可能被 AI 发现，然后 Error 就不能越过 checkpoint。

所以核心在于是你怎么设计和拆分 checkpoint， 你怎么做 Flow 和 Harness 交互，怎么保证两端都符合同一套规则体系，这才是 Shopify 从 RN 迁移到原生的价值。

然后 Shopify 做了一次实验，一开始先让团队做了一次 Proof of Concept，然后一个工程师花了一周时间，让 Coding Agent 根据现有 React Native 应用重建 SwiftUI 版本，之后项目继续扩大到六人，从 PoC 到新的 Swift/Kotlin Shop App 正式进入 App Store 和 Google Play，花了 12 周。

这个过程 Shopify 完全没有考虑新旧代码长期共存，它直接选择的是完全独立重构，然后重构之后的数据，原生页确实拿到了一些明显优势：

平台	Native	React Native	改善
iOS	2466 ms	3200 ms	-23%
Android	2233 ms	4433 ms	-50%

另外原来的 Shop App 长期保持 99.5%+ Session Stability，这次 Native 版本上线后提高到了 99.95%+，换算到崩溃 Session大概就是减少了一个数量级，还有 Android 包体积下降页比较明显：

平台	Native	RN	变化
iOS	68 MB	67 MB	+1 MB
Android	184 MB	293 MB	-109 MB

在 Pixel 上滚动 Feed 和页面切换时，没有针对性性能优化的第一版里，新的 Android 版本就已经能比较稳定做到 120 FPS。

另外 Shopify 还发现了 Agent 开发移动 App 的另一个瓶颈，那就模拟器太慢，现在 Coding Agent 修改代码很快，但是测试过程很慢，改代码可能只花了十几面，但验证一个结果可能需要十几分钟，所以 Shopify 也开始调整 App 架构，让业务逻辑可以脱离 UI 独立运行。

Business Logic 必须和 UI 完全解耦，可以直接在 Desktop Headless 环境运行。

所以 Shopify 给这些能力增加 CLI，因为不做不行，以前 Business Logic 你可能只需要验证一次，但是现在需要验证两次，所以必须做成自动化验证，同时压缩验证时间，不然换回原生成本还是 cover 不下来。

也就是在 Shopify 里，业务可以直接通过 Agent 对项目进行运行验证，不需要启动 Simulator，只有需要测试真实 UI 时，这套 CLI 又可以进入 Remote Mode，直接控制运行中的 App。

针对这个 Shop App 的迁移团队还做了一个叫 Tardis 的工具，让 Agent 能读取原生 App 的事件、Log 和内部 State，也能向 App 发送命令。

这样 Tardis 就可以同时记录 React Native 版本和 Native 版本在同一 checkpoint 的截图以及 Analytics Event，然后处理类似：

• RN 页面产生了哪些事件

• Native 页面产生了哪些事件

• 事件数量是否相同

• Payload 字段是否一致

• 页面关系是否一致

• 实体关系是否一致

所以其实在这里 Shopify 是针对 AI 给设计一种 Agent-addressable Architecture。

所以实际上 Shopify 选择回归原生，不是因为 AI 有手就行，主要是有了一套完成的架构工作流，可以做到需求和验证都尽可能通过 AI 有效解决，这才是 Shopify 选择回归原生的原因和理由。