2020 年，Shopify 把移动应用全面押到 React Native 上，此后五年一直是这个框架最响亮的旗手。2025 年 1 月，公司还在官方博客上写下「React Native 的未来是光明的」。一年半后，同一张官方工程博客宣布：所有移动应用回退到 Swift 和 Kotlin 原生开发，Shop 应用已经完成重建上架，最大的 Shopify 主应用正在迁移中。
让一家公司公开推翻自己五年前技术选型的变量，是 coding agent。Shopify 在声明里把逻辑讲得很清晰：2020 年选择 React Native 的三个理由——同一功能不用写两遍、没有移动端背景的开发者也能上手、不必再追平台特性对齐——前两个在 2020 年是硬约束，而在 2025 年之后，agent 已经能拿着 iOS 版本当参考实现 Android 版本，反之亦然。一份实现、两端交付的成本优势，被 agent 的跨平台翻译能力抹平了大半。
被重新定价的「写两遍」成本
原生开发从来没有消失过的成本是：每个平台各写一份、各维护一份。Shopify 没有否认这一点，他们的表述是这笔成本仍然存在，只是它不再是决定性因素。
变化发生在对 agent 能力边界的重新评估上。Shopify 从 2021 年开始用 LLM 辅助开发（早于 ChatGPT 发布一年），最初用于实现功能、修 bug、审代码。到 2025 年底，团队发现 agent 已经能承担足够多的实现、翻译、测试和评审工作，于是决定从第一性原理重新评估移动技术栈：用 Swift 和 Kotlin 重建核心应用的若干部分，效果出乎意料。
一个细节是重建方式的选择。渐进式迁移（brownfield）和整体重写（greenfield）之间，Shopify 这次选了后者，理由有三：agent 拿着 React Native 版本当参照写 Swift/Kotlin 的效率已经足够高；干净的重写不受历史约束；原型验证显示重建速度远超以往。2020 年他们从原生迁往 React Native 时选的是 brownfield，因为当时重写要花数年而且会阻塞新功能开发——同一个问题在不同技术条件下给出了相反的答案。
Helix：不让 AI slop 混进仓库的迁移系统
把 LLM 对着旧代码库一键重写是行不通的。Shopify 的原话是：即使先让模型收集信息、冻结成规格说明和任务文件再实现，产出的也是大量无法维护、无法上线的代码。为解决这个问题，他们造了一个叫 Helix 的系统。
Helix 的核心思路是渐进推进加多重门禁。开发者把 Helix 指向一个屏幕，它先读 React Native 源码，提出一组 checkpoint（把工作切成几分钟内可评审的小切片），然后逐个构建。每个 checkpoint 必须过四道关：用测试证明行为正确、与运行中的应用做视觉比对、在两个对抗性 AI 代码评审员面前存活、最后获得人类工程师的签核。每次评审的反馈都会被记住，循环随着迁移推进变得更自主。
这套流程针对的问题很具体：agent 生成的代码可以满足功能需求，同时引入重复代码、架构漂移或性能问题。Shopify 在迁移笔记里明确承认这一点——原生专家始终不可缺，仓库级规范、lint、测试、静态分析、性能检查和人工评审共同兜底。
Agent 反馈回路：把模拟器从循环里拿掉
Helix 之外，Shopify 还重构了 agent 的反馈基础设施。传统移动开发里，agent 改代码只要几秒，但通过模拟器验证结果要几分钟——依赖无障碍树或截图读取应用状态既慢又脆。反馈回路的速度决定了 agent 自主工作的上限。
Shopify 的方案是让业务逻辑与 UI 完全解耦，可以在桌面上无头运行，再通过 CLI 暴露给 agent。agent 检查应用状态、在页面之间导航、执行操作，全部在毫秒级完成，不碰模拟器。需要真机交互时，CLI 以远程模式连接模拟器，用命令驱动 UI 而不解析布局树。官方演示里，agent 以这种模式连续自主工作数小时。
Shop 应用的 12 周成绩单
第一个完成迁移的是 Shop 应用（App Store 购物类常年前列）。一名工程师花一周做概念验证，把尽可能多的 React Native 屏幕移植成 SwiftUI 应用，验证了逐功能对齐迁移的可行性。随后六名工程师搭建原生基础架构和主用户路径，各功能团队中途加入验证自己的领域。
从概念验证到全原生应用上架双商店，用时 12 周。官方公布的对标数据：
| 指标 | iOS | Android |
|---|---|---|
| 冷启动时间 | 2466ms（原 3200ms，降 23%） | 2233ms（原 4433ms，降 50%） |
| 会话稳定性 | 99.5%+ → 99.95%+，崩溃会话减少 10 倍 | 同左 |
| 应用体积 | 68MB（+1MB） | 184MB（原 293MB，减 109MB，降 37.2%） |
| Release 构建时间 | 基本持平 | 降约 75% |
迁移笔记还披露了配套工具：Pi coding agent 的迁移工作流扩展，配专项子代理负责源码审查、行为文档、平台方案、功能实现和一致性评审；一个叫 Tardis 的调试工具，给 agent 提供运行中应用的实时事件、日志和状态的访问通道，还能截图并抓取双版本应用在指定 checkpoint 的事件窗口做对比，自动核对事件名、次数和载荷字段。
特别处理过的细节是数据连续性：迁移后的应用必须让老用户无感知——保持登录态、推送正常、埋点事件照常发出且携带下游推荐系统需要的上下文。方案验收绑定内容哈希，改一个字的方案就作废之前的批准，确保评审通过的和实际实现的是同一份计划。
留给 React Native 生态的交接清单
Shopify 是 React Native 生态最大的贡献者之一，这次迁移对生态的影响通过三个开源库的安置方案体现。React Native Skia 由 Shopify 赞助至 2026 年底，核心维护者 William Candillon 之后会 fork 仓库换名发布，原仓库归档；每周下载约 200 万次的 FlashList 由 Shopify 继续修复破坏兼容性的关键问题，正在与数家公司洽谈长期托管；用户较少的 Restyle 维护到 2026 年底后归档。
对依赖这些库的团队来说，这是一个明确的迁移窗口期。而对 React Native 本身，Shopify 在文末给了体面的评价：2020 年的选择在当时是正确的，框架本身依然是优秀框架，Meta 团队是出色的维护者。这次调整的逻辑是前提变了：当「写两遍」的成本被 agent 大幅压缩，共享实现层带来的收益就撑不起它付出的框架层复杂度。
这个决策的样本意义大于结论本身。一家万人规模、移动应用服务全球数亿商户和买家的公司，公开把「agent 改变了成本结构」写成技术选型翻盘的理由，并附上完整的数据和工具链细节。跨平台框架解决的是人力稀缺问题，当 agent 把跨平台实现的边际成本压到接近单平台，这个品类的价值锚点就在松动。其他重度使用 React Native 或 Flutter 的团队，接下来要多回答一个问题：你的「写两遍」成本，现在还剩多少。
来源：Native is now the future of mobile at Shopify（shopify.engineering）、Migrating Shop app from React Native to native（shopify.engineering）