Shopify 回到原生：AI 改变了跨平台的成本账吗？

2025 年 1 月，Shopify 总结采用 React Native 的收益，表示会继续投入。2026 年 9 月 10 日，Mustafa Ali 在《Native is now the future of mobile at Shopify》中宣布转向 Swift 和 Kotlin。

同一家公司在相隔不到两年的时间里作出了不同的选择。新文章没有否定 React Native 的成绩，它的理由是：对 Shopify 的应用和团队来说，AI 让同一功能在两个平台各做一遍，不再像过去那么贵。

这可能改变技术选型的答案。实现成本与长期保持双端一致的成本，需要分别估算，再一起比较。

共享代码当年解决了真实的问题

在《Five years of React Native at Shopify》里，团队回顾了三个目标：减少重复实现，让开发者能跨平台工作，少追赶功能一致性、多交付用户价值。团队认为这次转向取得了成效。

代码共享的好处很具体。一次业务修改落在共同实现里，通常可以少做一轮重复开发；调配人员时，也不必总被 iOS、Android 的技术分工卡住。2025 年的总结还肯定了热重载的开发体验，以及 TypeScript 带来的跨平台协作能力。

代价在同一篇文章里也写明了：调试工具、框架升级、第三方依赖都要持续投入，硬件接口、后台任务和部分性能敏感场景仍然离不开原生代码和原生工程师。

所以旧决策并非没看到抽象层的成本，当时的判断是省下来的工作值得付这笔钱。新文章同样承认，Shopify 的 React Native 应用可以很快。把这次迁移解读成“React Native 性能不行”，会漏掉它给出的主要理由：AI 降低了重复实现的相对成本，而贴近平台能力、使用第一方工具的收益一直存在。

选型比较的是各项成本的权重，代码有几份只是其中一项。以前占大头的环节变便宜了，原来可以接受的框架维护开销就值得重新衡量。

框架升级前，团队重新比较了两种方案的成本

Shop 团队在《Migrating Shop app from React Native to native》中补充，他们当时正准备投入 React Native New Architecture 迁移。这项工作本来就要重新检查原生模块集成、渲染，以及共享代码与平台代码的边界。

所以摆在面前的，并不是一条零成本的旧路和一条要大兴土木的新路。继续用 React Native，同样有一笔即将发生的工程投入，团队在承诺这笔投入之前，先试了 SwiftUI 和 Jetpack Compose。

是否正面临框架升级，会影响这笔成本该怎么算。对一个运行稳定、近期没有大规模升级压力的应用，迁移要证明自己能抵消额外投入；对一个本来就要重做若干基础环节的应用，可比较的选项更多。两类团队用的不是同一张预算表。

Shopify 描述的 AI 收益主要落在三处：参照一端的实现去写另一端，帮助开发者进入不熟悉的技术栈，借助共同规范、测试和审查节点维持双端一致。

但两套原生代码仍然要分别构建、测试、发布。两个平台处理系统授权、应用进入后台和恢复前台的方式可能不同，生成出相似的页面并不能证明行为一致。翻译代码变快了，平台知识的需求并没有消失。

十二周的参照物是已经存在的产品

官方报告称，Shop 从概念验证到原生应用上架用了 12 周。这个数字需要连同它的条件一起读。

最初是一位工程师用一周做出 iOS 概念验证，尚未达到生产可用。决定迁移后，六位核心工程师搭建原生基础和主要用户流程，功能团队中途加入，校验各自负责的部分与边缘情况。

AI 模型面对的也不是一张白纸。旧应用已经说明了屏幕怎么组织、操作怎么推进、数据从哪里来，团队也清楚哪些行为必须保留。旧产品本身就包含了多年开发积累下来的答案。

如果团队还在摸索用户到底要什么，或者旧代码里的规则互相矛盾，就不能直接用这十二周来估算自己的开发周期。重写一个现成的产品，和发明一个新产品，消除的不是同一种不确定性。

两个平台在迁移后的表现也有差别。以发布包体积为例：

这是 Shop 团队公布的版本对比，不是跨框架的独立基准测试。报告同时提到，迁移中他们精简了应用，移除部分页面，调整部分流程，所以差异里混着这些改动，不能全部算到语言或框架头上。iOS 基本持平而 Android 明显缩小，也提醒我们：某个平台上的显著收益，不意味着另一个平台的每项指标都会跟着变好。

不共用实现以后，要共用什么

不再共用一份代码后，团队仍要保证同一个功能在两个平台上按相同的要求运行。

Shop 的迁移报告在这一点上写得很细：既要保留功能行为，也要保留下游系统依赖的分析事件。老用户更新后应继续保持登录、照常收到推送；一个看起来没变的交互，也要发出正确的事件和上下文。界面一样，背后的行为仍可能不同。商品页打开时少发了一个事件，画面上看不出来，依赖这条事件的下游系统却可能出问题。

为此，Shop 团队描述了一套基于 Pi 编码 Agent 扩展的迁移流程：先检查源实现，准备需求与平台方案，再实施和审查。计划的接受记录绑定内容哈希，计划一变，旧的接受记录即告失效。

他们还开发了 Tardis，让 Agent 读取运行中应用的事件、日志和状态，并向应用发命令。在对照检查中，团队在命名检查点捕获旧 React Native 版本与新原生版本的截图，以及对应时间窗口内的事件记录。他们比较事件名称、数量和载荷字段，同时区分时间戳、页面 UUID 这类每次运行都会变的值。

界面代码可以分别编写，但两个平台仍要遵循相同的用户流程和行为要求，并使用同一套检验材料。

公司整体迁移文章则介绍了 Helix。它把工作切成有顺序的小检查点，结合测试、视觉检查、代码审查和人工确认往前推。那篇文章还提出，把业务逻辑和 UI 分开，让逻辑能在桌面无界面环境中运行，再通过 CLI 交给 Agent，以缩短依赖模拟器的反馈过程。

两份文章分别从公司路线和 Shop 项目介绍了这些做法。它们共同说明的是投入方向：团队一边改应用，一边建设让 Agent 能看见行为、反复检查结果的工具。开发这些工具、准备两个平台共用的测试材料，也都是迁移的成本。离开共享代码不等于不再需要共享，规范和验证如果不能复用，两套实现仍会逐渐走散。

其他团队先做一小段自己的对照

准备重新评估移动技术栈的团队，我倾向于先看一段有代表性的流程，再决定要不要全量重写。

可以选一条确实涉及平台差异的业务路径。下面是我构造的一个试验场景，并非 Shop 的原始实测：用户从推送进入商品页，在弱网下加入购物车，退到后台后再回来。为这一条路径写清状态和事件要求，固定测试数据，然后比较现有实现与原生原型。

观察项不要只有启动速度。登录态有没有丢，重复点击会不会重复提交，返回路径对不对，无障碍信息是否完整，都会影响判断。业务逻辑如果已经能独立测试，就复用这些测试；平台生命周期和真机行为还得另外验证。

成本记录里，把模型调用和实现工时，与原生专家审查、测试工具建设、双端集成分开记。这样才看得出节省来自哪里，有没有转嫁给别的环节。之后再做一次小的业务修改，看两套实现保持一致要花多少工作。

这类试验还应保留继续用 React Native 的选项。AI 同样能帮忙改 React Native 代码、补测试、定位问题。原生方案要赢的，是经过合理改进的现有方案，而不是一个故意放着不管的旧版本。

对原生经验不足、团队规模有限，或者业务仍高度依赖跨端快速迭代的项目，共享实现的收益可能依然很高。Shopify 能建设迁移流程和调试工具，不代表每个团队都能以同样的代价获得这些条件。

截至两份官方文章发布时，已完成原生迁移的只有 Shop；面向商家的 Shopify app 仍在进行中，其余应用计划随后迁移。现有证据支持的是一次已完成的 Shop 迁移和一个更广泛的技术方向，还不能当作所有应用长期维护结果的结算。对其他团队来说，需要重新计算的是在 AI 之后，用什么总成本让应用持续正确地运转，“AI 能不能把代码写出来”只是其中一项。