Shopify 从 React Native 回归 Swift 和 Kotlin
文章摘要
Shopify 工程博客发布了一篇由 Mustafa Ali 署名的文章，宣布公司正在把所有移动应用从 React Native 迁回原生的 Swift 和 Kotlin。文章副标题直白地点出了理由：编码智能体两次改变了构建移动应用的成本结构。
为什么当年选 React Native，今天又要离开。2020 年 Shopify 全面押注 React Native，出于三个原因：不再把同一个功能做两遍、让开发者能跨栈工作、少花时间追赶双平台功能对齐。作者承认这次押注非常成功。2025 年 1 月他本人还写过文章说 React Native 前景光明、Shopify 会继续投入。但作者强调，”我们不会因为一个决定当初成功过就一直守着它”——当核心假设变了，就应该重新问它是否还成立。而 LLM 恰恰动摇了 2020 年那个决定背后的核心假设。
Shopify 从 2021 年（比 ChatGPT 早一年）就开始用 LLM 写软件。到 2025 年底，模型已经强到让他们怀疑”把软件做两遍”是否还等于”两倍工作量”。他们用 LLM 把几个核心模块在 Swift/Kotlin 里重建了一遍做原型，结果出乎意料地好：智能体能以 iOS 版本为参照实现 Android 版本（反之亦然），能帮开发者快速在非主力技术栈上产出，并通过共享规格、测试和评审检查点大幅降低维护双平台一致性的成本。作者也很坦率：双平台的成本并没有消失，只是不再是决定性因素了；React Native 应用可以很快，Shopify 自己的就很快，改变的是”共享实现”的优势被智能体削弱了，而”为每个平台单独构建”的优势依然存在。
开源库的去向。这部分对社区影响最直接：React Native Skia 由 Shopify 赞助到 2026 年底，之后 William Candillon 会 fork 出去以新名字继续维护，原仓库将归档；FlashList 每周约 200 万次下载，Shopify 会继续修复破坏兼容性的关键问题，并正在与几家公司商谈长期接管；Restyle 用户基数较小，直接归档，2026 年底后停止维护，欢迎社区 fork。
怎么迁移。Shopify 有 Shopify、Shop、Point of Sale、Inbox 等多个大型应用。这次他们放弃了当年迁入 React Native 时用的渐进式（brownfield）路线，选择彻底重写（greenfield），因为 LLM 擅长以 React Native 版本为参照用 Swift/Kotlin 重建，重写还能摆脱历史包袱。Shop 应用是第一个迁完的——从概念验证到完整原生应用上架，只用了 12 周。拥有 300 多个界面、桌面与锁屏小组件、Apple Watch 应用、Siri 快捷指令的 Shopify 主应用正在迁移中，年内发布。
防止 AI 产出垃圾（preventing slop）。作者强调，直接把 LLM 指向 React Native 代码库让它一次性重写是行不通的，哪怕先冻结成规格和任务文件，最后得到的也是大量无法上线的、不可维护的代码。他们为此构建了一套叫 Helix 的系统：开发者把 Helix 指向某个界面，它读 React Native 代码并提出一串”检查点”（可以在几分钟内评审完的小块工作），然后逐个检查点推进——每一步都必须用测试证明行为、在视觉评审中与运行中的应用比对、通过两个对抗性代码评审者、再由人类点头才能提交。每次评审的反馈都会被记住，迁移越往后循环越自动化。
为智能体设计的反馈闭环。文章里技术含量最高的一段是关于模拟器瓶颈：智能体改代码只要几秒，但测试要几分钟，因为它们依赖无障碍树或截图来读取状态、执行操作、验证结果。Shopify 的解法是让业务逻辑完全与 UI 解耦、能在桌面上无头运行，并通过一个 CLI 暴露给智能体，把迭代从分钟级降到毫秒级；需要真机/模拟器时，CLI 可以远程模式驱动 UI，无需检查布局或无障碍树。作者称这让智能体能连续自主工作数小时。
HN 评论精华
这条帖子拿到 1260 分、933 条评论，是本期讨论最激烈的一条。发言者大致分成三派：认为这是行业转折点的、认为这是又一轮技术时尚轮回的，以及质疑”AI 让重写变便宜”这个论证本身的。
Shopify 高管在评论区下场。用户 fnthawar2（据 aprilthird2021 指认，即 Shopify 工程负责人 Farhan Thawar）贴出文章中”核心假设变了就重新评估”的段落。当 fnikacevic 问工程师是否需要专门培训时，mustafa01ali（文章作者本人）回复：”当然需要，我们在全面转向之前就投入了对团队的原生技术栈培训。”
最热的子话题竟然是 App Store 审核时长。joshstrange 列出原生路线的几大代价：审核时间、无法热更新、双平台同步、还要再做 Web。joenada 反驳说审核通常 24 小时内、这个说法过时了。joshstrange 随即拿出自己的数据：他管理约 20 个应用，最快一次 8 小时（6 月 20 日），此后最近三次分别是 40、67、98 小时，公司还有两次超过一周；他引用 Marco Arment 在 ATP 播客上说自己的应用卡审两周多，并把原因指向 vibe coding 带来的审核量暴增。他的结论是：问题不在平均值而在完全无法预测——”我没法围绕随机性做计划”，所以他宁可用 Capacitor 加 OTA 更新。ftchd 佐证说同一个开发者账号、同一个品类，这周一个应用卡了 9 天，另一个 8 小时就过。manmal 给出实用建议：超过 36 小时就撤回重新提交，多半只是卡在某个队列里。
“这不是技术判断，是时尚轮回”。quotemstr 一句”时尚的轮子又转了一圈”获得大量附和。jmknoll 反驳说这不纯是时尚：React Native 一直有性能和体验代价，很多人认为为了产品迭代速度值得；LLM 改变了这个权衡，组织不重新评估才是失职。paxys 描述了一条常见路径：新公司先做纯原生（只有 iOS、功能少），再转 React Native/Electron（要支持更多平台、迭代快），最后又回到纯原生（养得起每个平台的团队）。afavour 提醒当年 Airbnb 回归原生时他也有同感——对 Shopify 和 Airbnb 这种体量说得通，不代表十人小团队该照做。SV_BubbleTime 说得更直接：”我们要么用 Flutter，要么就根本不发应用。全原生是个 non-starter。我根本不在乎 Shopify 怎么做，因为他们有成百上千人。”
对论证逻辑的质疑。kamaal 提出一个被反复引用的悖论：”如果 AI 能让任何语言做任何事，为什么要离开 React Native？”他怀疑这更像内部派系争夺地盘而非技术判断。basepurpose 同样表示：”如果智能体让原生变容易了，那它让 React Native 扩展起来应该更容易才对，这个决定说不通。”gargs 提出了最精炼的一版：”如果智能体强到能把 React Native 代码高效转成原生，那是什么阻止它们去改进 React Native 本身？”stickfigure 泼冷水说这些评价都为时过早——”等新应用推出、用户满意了再说。这种规模的重写脱轨的概率足够高。我相信 Digg 的工程师当年也为他们的重写而自豪。”prisonguard 遗憾地说”这次切换唯一的理由竟然是 AI，我本来很想看到关键路径上的性能基准”。
有人已经做了同样的事。atonse 描述自己的经历：晚上 12 点半给 Codex 一个目标，它清点了 React Native 里的每个界面、建好 iOS 和 Android 目录、用 Maestro 做端到端测试，早上起来两个平台都跑通了——大约 6 小时、他睡着的时候完成的。他强调自己既不会 Swift 也不会 Kotlin，”我真的看不出 React Native 还有什么意义”。这条引来了尖锐的追问：fourside 问”你不用 Android、也不懂 Kotlin，那你怎么评估 Android 构建的质量？”；nevertoolate 说”所以你现在有两个自己看不懂的 vibe coded 应用，这已经是红旗区了”；jgalt212 问”你不介意公司应用里的专有 IP 被吸进训练数据？”；greenowl 则干脆说”还有人说 AI 不会抢软件工程师的工作”。bearjaws 和 aenis 给出了更审慎的版本：前者花两个月完成重写、一周内出 PoC，苹果审核意外地快；后者是一家”慢而无聊的公司”，工程量约 4 周、算上发布流程约 3 个月，而且那是在今年 2 月、模型还没法跑通宵任务的时候。netshade 提供了一个重要的反证：他主导过一次中等规模 React Native 应用的原生重写，大部分工作是在 2026 年 1 月之前、没有 LLM 辅助完成的——他认为”LLM 让原本太贵的迁移变得可行”这个叙事不准确，React Native 持续的升级困难、与底层框架的阻抗失配、库质量参差本身就足以支撑这个决定。
Helix 和”为智能体设计架构”是被低估的部分。aecorredor 说文章里最有意思的是 Helix 和”把业务逻辑与 UI 拆开，好让智能体通过 CLI 驱动状态”这一段，希望看到更深入的博文，但同时吐槽：”我很意外他们把’状态与 UI 解耦’说得像什么开创性的东西，这明明是任何理智、可测试的应用长期以来的基础。”philipwhiuk 对 Helix 的循环机制提了个简洁的问题：”所以……局部最优？”randysalami 则注意到文章自相矛盾之处：明明说 greenfield 完胜 brownfield，转头又说 Helix 采取”更渐进的方式”。
行业外溢。ceejayoz 预测”未来一年会看到很多大组织这么干”。dpark 说他惊讶这种事还没更普遍，”LLM 突然让维护多个原生应用变得合理了，我很想看到这开始取代 Electron 及其同类”。pkaler 从温哥华 Cordova Street 的窗口写下了近二十年的观察：团队跳上最新的跨平台框架，以为能省人头，结果”20 个 iOS 工程师 + 20 个 Android 工程师”变成了”20 个产品工程师 + 20 个工具和框架工程师”——低公分母的应用体验是真的，省下的人头是假的。sintaxi 补充了一条重要更正：Cordova 的目标从来不是做”跨平台生产力乘数”，而是希望自己有一天不必存在——推动浏览器获得地理位置、加速度计、通讯录、相机等原生能力，而这个目标最终达成了。