Shopify 回归原生开发，AI 改写的是跨平台复用的成本账

作者：林岚｜OC 开发者生态编辑

据 Shopify 工程团队介绍，公司正将移动应用从 React Native 迁回 Swift 与 Kotlin。Shop 已完成迁移，其他应用仍在推进。团队并没有宣判 React Native 失败，而是认为编码 Agent 改变了维护两套实现的成本条件。

一句话结论：AI 没有让两端开发变成零成本，它让“必须共用一份实现才划算”不再是唯一答案；真正决定迁移能否成功的，是共享规格、快速测试和逐步验收。

曾经正确的选择，为什么可以被重新计算

跨平台方案解决的不是语言喜好，而是组织问题。一个功能要在两个系统上表现一致，就需要两份实现、两组平台知识和持续对齐。共享代码能减少其中一部分重复劳动，也能让更多开发者参与移动项目。

原生方案则更贴近平台自己的能力与工具。但如果一个团队只有少数移动工程师，平台优势很可能抵不过人员与维护压力。技术路线从来不是抽象排名，而是人员、产品和时间共同约束下的选择。

Shopify 的变化，是认为 Agent 已经能承担足够多的实现翻译和对照工作，让原生能力重新获得更大权重。这是该公司的工程判断，不是所有团队的迁移指令。

对于独立开发者尤其如此：一个人同时理解两端生命周期、签名发布和故障诊断的负担，不会因为代码可以生成就消失。AI 能补充实现能力，但不能自动补齐长期维护责任。

共用规格，比共用文件更难伪装

从“共享实现”转向“两端实现”，不意味着放弃复用，而是可能把复用上移到规格、数据契约和验收条件。

例如，购物车优惠的顺序、库存不足时的提示、离线修改恢复后的冲突处理，应该先有明确行为，而不是让 Android 版本照着 iOS 截图猜。截图能告诉模型按钮在哪里，无法完整说明按钮背后的业务约束。

如果两端分别生成，再由人凭印象判断是否一致，节省的编程时间很快会流向测试和客服。反之，一份可执行的行为说明能同时约束两个实现，也能在以后修改规则时发现差异。

一次性重写，恰恰不是这次经验的重点

Shopify 披露的 Helix 工作流，把迁移拆成小检查点，依次经过行为测试、视觉核对、对抗式代码审查和人工确认。公司称 Shop 从概念验证到上架原生重建版本用了十二周；这个周期属于该项目，不是迁移报价单。来源：工程团队说明

值得注意的是，“整体重建”与“一次生成”完全不同。前者描述最终替换方式，后者描述工作过程。可以选择新建代码库，同时坚持每一小步都能检查、回退和解释。

这里的关键也不是多加几个审查 Agent。多个模型如果都沿用错误规格，仍可能一致放行。人工确认需要掌握独立的产品依据，而不是只看几份互相赞同的评语。

真正拖慢 Agent 的，可能是它看不见应用状态

移动应用测试的反馈常常比改代码慢。构建、启动模拟器、登录、导航到目标页面，再观察结果，每一步都可能产生不稳定因素。

Shopify 的另一项做法，是让业务逻辑脱离界面，并通过命令行暴露状态和动作，使大量检查不必依赖模拟器。这并非不要 UI 测试，而是把不需要视觉环境的验证移到更快、更确定的位置。

一个结算规则可以在无界面环境中覆盖大量输入；键盘遮挡、无障碍焦点和手势冲突，则仍要回到真实界面。把两种测试混在一起，既慢，也容易出现“逻辑正确但用户操作不了”的遗漏。

对其他团队，先验证成本假设再谈迁移

最稳妥的起点不是宣布重写整个应用，而是选择一个边界清楚、又足够接近真实复杂度的功能做对照。

记录的不应只有生成用了多久，还应包括审查、平台适配、回归、上线后的问题修复，以及交给另一位工程师维护时的理解成本。如果最后一项异常高，说明团队可能获得了更快的初稿，却没有获得更便宜的软件。

还要把开源依赖的维护纳入计划。大用户改变路线后，相关库的维护者和资源也可能变化。即使自己的技术选择不变，也值得重新确认关键依赖由谁负责，而不是把历史上的赞助关系当作永久承诺。

关键事实

• Shopify 正推进原生迁移，并非所有应用已经切换完成。
• 公司仍认可此前 React Native 的收益。
• 新路径依赖小步验收与可供 Agent 快速测试的架构。

OC 判断

最有价值的消息不是“原生赢了”，而是代码复用的经济条件正在变化。未来团队共享的可能越来越多是规格与验证，而不是每一行实现。谁能把业务意图写清楚，谁才更可能真正拿到 AI 的效率收益。

为什么重要

• 对移动开发者：平台知识仍重要，验证方式正在变。
• 对团队：先测完整维护成本，再决定是否重写。
• 对用户：技术栈迁移应最终体现为稳定性和体验，而不是发布口号。

参考来源

• Shopify Engineering：Native is now the future of mobile at Shopify