12 周推翻六年基石
2026 年 9 月 10 日，Shopify 宣布放弃推行六年的 React Native，用 Swift 和 Kotlin 重写旗下所有移动端应用。第一个迁移目标 Shop App 从概念验证到双端原生全量上架，只花了 12 周。
这不是一场预谋已久的技术栈交接。2025 年 1 月，本次博文的作者 Mustafa Ali 还在公开承诺会继续投入 React Native。**20 个月后的态度反转，直接动摇了跨平台框架的存在前提：把同一个功能写两遍，成本高到无法承受。**原文给出的理由很直白——组织不会因为一个决定当年成功就抱住不放，核心假设变了，就该回头重新问它是不是还成立。
变化来自模型。Shopify 从 2021 年就开始用 LLM 写软件（比 ChatGPT 早一年），最初只用来实现功能、查 bug、评审代码。到 2025 年底，模型不再只是让人写得更快，而是让团队开始怀疑「构建两次软件是否还等于两倍工作量」。
图：Shopify 从 React Native 迁到原生移动开发的演进示意。来源：Shopify Engineering
拒绝黑盒大一统翻译
把 LLM 直接指向 React Native 代码库、让它一次性在原生里复现同样功能，这条路被官方判了死刑：最后你只会得到一大堆不可维护、根本发不出去的代码，哪怕事先让它收集信息、冻结成规格和任务文件也一样。
Helix 走的是相反方向。开发者把 Helix 指向一个屏幕，它读 React Native 源码，先提出一串能在几分钟内评审完的 checkpoint，也就是有序的小切片。然后逐个 checkpoint 推进，每个都要用测试证明行为、在视觉评审里跟正在运行的 App 比对一致、扛过两个对抗式代码评审员，再拿到人工点头才允许提交，下一个才开始。每一轮评审的反馈都会被记住，迁移越往后越自主。
**把自动迁移切成人类可验证的检查点，黑盒的全局翻译就变成了白盒的工程流水线。**落到具体动作上，就是让 agent 拿着 iOS 实现当参照，在 Android 上严丝合缝重做一遍，反过来也一样。
图：Helix 正在用 Swift / Kotlin 重建 Shopify App 的屏幕组件。来源：Shopify Engineering
瓶颈不在模型，在验证速度
Agent 改代码只要几秒，验证结果却要几分钟，这件事把整个循环拖成了手工活。移动端的验证尤其难：模拟器要靠 accessibility tree 或截图拿应用状态、执行动作、确认结果，React Native 的热重载只能缓解，解决不了。
Shopify 的解法是把架构改成同时服务人和 agent。核心原则是业务逻辑与 UI 解耦，并且能在桌面 headless 运行，再通过一个 CLI 暴露给 agent——agent 可以查状态、跨模块跳转、执行动作，全程不碰 UI。迭代从分钟级压到毫秒级，agent 才有机会连续自主工作几个小时。需要真机模拟器时，CLI 用 remote mode 直接下命令驱动界面，不再解析布局树。
**剥离渲染链路之后，模型的批量试错优势才真正兑现。**也正因为构建和验证循环够快，这次他们一反 2020 年的渐进式迁移策略，选了从零重写的 greenfield：2020 年不敢重写是因为要耗上数年且期间无法继续发版，现在这个约束没了。
3000 人团队的经验能不能迁移
HN 首页这条 1085 分、775 条评论的讨论里，大厂路径的普适性成了主战场。
质疑方的论据是规模。有评论把 Shopify 的约 3000 名工程师和 2008 年 Chrome 首发时的约 60 人放在一起对比，结论是大厂靠人力堆出来的工具链，中小团队复用不了。反驳方认为这种跨时代对比没有意义：2008 年的 IDE、库生态和工具链跟今天不是同一回事，Chrome 1.0 当时连打印、无障碍、RTL、图形加速都没有，拿它代表同等工程复杂度是错配。
站队之外，善后动作倒是清晰。每周约 200 万次下载的 FlashList 继续修关键兼容问题，正在和其他公司谈长期接管；React Native Skia 的赞助到 2026 年底为止，之后由原维护者 fork 改名继续，原仓库归档；用户量小的 Restyle 直接归档，2026 年底后停止维护。
Agent 把同一套业务逻辑翻写成两份原生代码的成本打下了几个数量级，跨平台框架用性能和原生体验换来的那部分复用，就不再划算了。这不是 React Native 变差，是它的折价理由变弱了。
参考链接：
- Shopify Engineering Blog 报道
- Hacker News 社区讨论
