Native 现已成为 Shopify 移动端的未来(2026)

编码智能体把移动应用的构建成本降了两次,Shopify 因此从 React Native 回到 Swift 和 Kotlin;作者解释了让核心假设改变的是什么,以及这次迁移的代价与收获。

中文
复制
题图:夜色里的插画,一双手展开一张写满路线图的纸卷,纸上的岔路通向左右两台手机——左边是青色的 React Native 屏,右边是绿色的原生屏,背景是树林与代码碎片

编码智能体两次改变了移动应用的构建成本。Shopify 正因此从 React Native 回到 Swift 和 Kotlin。

2020 年我们决定全面押注 React Native,这个赌注极为成功。功能只需写一次,省下大量时间;没有移动端背景的开发者也能为我们的应用做贡献;我们也不必再疲于追赶功能对齐。

2025 年 1 月,我写过 React Native 前景光明,Shopify 计划持续投入。基于当时掌握的情况,这话没错。React Native 在我们这里运转良好,至今仍是一个出色的框架。但自那以后,编码模型大幅进步,对我们的应用和团队来说,用 Swift 和 Kotlin 实现同一个功能的成本已不复从前。

我们不会因为一个决定曾经成功就死守它。当核心假设发生变化,我们愿意回头问一句:这还是正确的选择吗?LLM 改变了我们 2020 年那个决定背后的一个核心假设,于是我们从第一性原理出发重新评估了移动技术栈。

评估的结果把我们带回了原生。

为什么切回原生

2020 年我们决定从原生转向 React Native,理由有三:

  • 不再把同一个功能写两遍
  • 让开发者能跨技术栈工作
  • 少花时间追赶功能对齐,多花时间交付价值

React Native 一直兑现着这些好处。我们确实在性能优化、改进 React Native 的关键基础模块、跟进框架更新和外部依赖上投入了大量时间和资源,但这些代价可以接受。使用 React Native 的收益,远远超过我们在这些方面必须做的投入。

Shopify 从 2021 年就开始用 LLM 构建软件(比 ChatGPT 还早一年!)。最初我们用它实现功能、排查和修复 bug、审查代码。随着模型变强,我们交给它的任务复杂度也在提高。到 2025 年底,它不再只是帮我们更快地写代码,而是让我们开始怀疑:把软件写两遍,是否还意味着两倍的工作量。

我们决定重新评估移动技术栈,并开始做原型,看看当初的技术选择是否依然成立。我们用 LLM 把几个最大应用的核心部分用 Swift 和 Kotlin 重写了一遍,效果之好出乎意料。智能体:

  • 可以参照 iOS 版本在 Android 上实现某个功能,反之亦然
  • 帮助开发者在自己的主技术栈之外快速上手并有效贡献
  • 通过共享的规格、测试和评审检查点,大幅降低了维持双端一致性的成本

原生开发仍然意味着要在两个平台上构建和维护软件,这笔成本并没有消失。变化在于,agent 现在能承担足够多的实现、转换、测试和评审工作,它不再是 2020 年那样的决定性因素。 React Native 应用可以很快,我们的就很快。我们做出这一改变,是因为 agent 削弱了共享实现带来的优势,而针对各平台分别构建的优势依然存在。原生让我们更贴近平台能力和第一方工具链,代码与平台之间的框架层和依赖层也更少。

我们 React Native 开源库的未来

在讲迁移方式之前,我们想确保这次过渡干净利落。从一开始,我们就想回馈 React Native,让它变得更好。我们发布的开源库已经在各自类别中成为首选。感谢社区的热烈反响,我们也会确保这次过渡平稳、没有意外。

React Native Skia

Shopify 将继续赞助到 2026 年底,之后由 William Candillon 继续推进。他会在接下来几个月内 fork 该仓库,并以新名称发布这个库。过渡完成后,原仓库将被归档。我们会一路发布进展,让所有人都有充足时间迁移。如果你的应用依赖这个库,请考虑赞助它。

FlashList

这个库每周约有 200 万次下载,已经成为 React Native 中渲染高性能列表的默认方案。鉴于它对生态的重要性,Shopify 会继续修复破坏兼容性的关键问题。我们正在与几家公司商讨由他们长期接手 FlashList。如果你有兴趣,可以在这里联系我。

Restyle

Restyle 的用户量比其他几个库都小,所以我们决定归档这个仓库。我们会继续维护它到 2026 年底,之后就不再维护了。欢迎任何人 fork 并接手推进;如果有团队愿意接手,我们也会协助交接。

我们如何迁移

Shopify 有几个大型应用(ShopifyShopPoint of SaleInbox)。全球数百万商家和买家每天都靠它们谋生、从自己喜爱的品牌购买商品。 我们讨论过是逐步迁移到原生(brownfield),还是从头重写(greenfield)。过去迁移到 React Native 时,我们对几个最大的应用选择了 brownfield,因为重写要花好几年,而且重写期间不得不停止发布新功能。 但这一次,greenfield 明显胜出,原因如下:

  • LLM 擅长以 React Native 版本为参照,用 Swift 和 Kotlin 实现功能
  • 它给了我们一张白纸,可以不受以往任何约束,用最好的方式重建
  • 我们的原型表明,重建这些应用的速度远快于编码 agent 出现之前

Shop 应用常年位居应用商店购物类榜单前列,是第一个完成迁移的。在 AI 的辅助下,团队从概念验证到完全重建的原生应用上架,只用了 12 周。我们在这里详细写过这次迁移。 Shopify 应用(我们最大的应用,有 300 多个页面、主屏和锁屏小组件、Apple Watch 应用、表盘复杂功能、Siri Shortcuts 等)的迁移也在进行中,将于今年晚些时候发布。其余应用也会很快迁移。

防止 slop

把 LLM 直接指向 React Native 代码库,试图一次性把同样的功能用原生实现出来,这很诱人,但行不通。即使你让它事先尽可能多地收集信息,把这些固化成规格说明和任务文件,再照着实现,最终得到的也是一大堆无法维护、无法发布的代码。 为了解决这个问题,我们构建了一套叫 Helix 的系统,采用更渐进的方式。它不指望第一次输出就是对的,而是构建了一个循环:不完美的尝试根本无法向前推进,直到它变成好的结果。 开发者把 Helix 指向某个页面。Helix 读取 React Native 代码,提出一系列检查点(把工作切成小的、有序的片段),每个检查点几分钟就能审完。然后它逐个检查点地构建:每个检查点都必须用测试证明其行为,在视觉审查中与运行中的应用一致,经受住两名对抗性代码审查者的审查,并得到人类点头,才能提交并开始下一个。每次审查的反馈都会被记住,所以随着迁移推进,这个循环会越来越自主。

Helix 使用 Swift 和 Kotlin 重建 Shopify 移动应用中的界面 这套方法效果极好,让我们能用零头的时间重建应用。

实现快速反馈循环

对模拟器的智能体控制一直是个瓶颈。我们发现自己得时刻盯着它们,因为它们没法可靠地构建、测试和迭代。我们构建了工具,让智能体能够自主复现 bug、修复并验证修复,但它又慢又脆。React Native 的热模块重载能缓解这个问题,但解决不了,因为模拟器控制本身很慢。这主要是因为依赖无障碍树或截图来获取应用状态、执行操作和验证结果。智能体几秒钟就能改完代码,但测试输出要花好几分钟。这让迭代变得极慢且依赖人工。模型再强也没用,如果它没法快速测试自己的工作——这在移动端尤其困难。

我们正在通过设计同时服务于人类和智能体的应用架构来解决这个问题。核心原则是业务逻辑必须与 UI 完全解耦,并且能在桌面端无头运行。然后我们通过 CLI 把它暴露给智能体,让它们能在毫秒级而非分钟级迭代,完全不用碰模拟器。

使用 CLI 导航应用并执行操作 CLI 让智能体能够检查应用状态、在不同区块间导航、执行操作,全程无需触碰 UI。这带来了极快的反馈循环,让智能体能够连续数小时自主工作。 当需要与模拟器交互时,CLI 可以通过远程模式连接它们,用命令驱动 UI,而无需检查布局或无障碍树。这带来了极快的性能和 E2E 测试。

这是实时速度(未加速)

下一步

我们要把所有移动应用迁移到 Swift 和 Kotlin,并在整个过程中全程借助 AI。Shop 已经以完全原生应用的形式上线,Shopify 应用正在推进中,其余应用也会很快跟上。我们的节奏很快,但不会因此降低标准。每一次重写都必须达到或超越用户今天所期待的性能、稳定性、可访问性和产品质量。这不是把同样的应用换种语言重写一遍。我们重建它们,是为了让人和 agent 都能快速理解、测试和修改。

迁移不是终点。成功意味着我们的团队能比过去更快地为商家和买家交付更好的体验。我们会用产品迭代速度、应用质量,以及 agent 能自主完成多少工作来衡量这一点。

我们会分享一路上的收获,包括对 Helix、我们这套面向 agent 的架构,以及我们如何用 agent 构建移动应用的深入解读。我们曾公开谈过从 React Native 中学到的东西,这次转型我们同样打算保持公开。

这是我们承接过的最有野心的移动工程之一。如果你想参与构建下一代 Shopify 移动应用,我们正在招聘移动工程师、基础设施工程师,以及在 AI 与软件工程交叉领域工作的开发者。

致谢

对现在的 Shopify 来说,原生是正确选择,但在 2020 年,React Native 是正确选择。那次成功离不开让它运转起来的人。

Meta

感谢 Meta 的 React Native 团队,你们是这个框架出色的守护者,倾听我们的反馈,多年来与我们紧密合作。正因为你们在架构、性能、工具链和社区上的投入,React Native 才有了今天的长足进步。

William Candillon

感谢你创造了 React Native Skia,并把它推进到远超我们所有人想象的程度。你重新定义了 React Native 中图形与动画的可能性,我们很期待看到你接下来把它带向何方。

Software Mansion

感谢你们为 Reanimated 付出的所有努力,感谢你们倾听我们的反馈,也感谢你们帮我们解决了应用中一些最棘手的动画和性能问题。

Shopify 工程师们

数百名工程师参与了 React Native 的采用、应用迁移、共享基础设施建设、性能优化、集成维护,以及回馈生态。你们中的许多人重新做回了初学者,挑战了长期以来的假设,在持续为商家和买家交付的同时,让这次转型得以成功。谢谢你们。

React Native 社区

感谢每一位使用我们开源库、贡献代码、报告问题、质疑我们决策、分享所学所得的人。你们的贡献和反馈——包括那些尖锐的——让我们的工作变得更好。 过去六年里建立起来的工具、经验与关系,将继续影响 Shopify 构建移动应用的方式。我们深深感谢每一位参与其中的人。

来源: Shopify Engineering← 返回首页