Shopify 宣布从 React Native 全面迁回 Swift 和 Kotlin 原生开发

原生开发如今已成为 Shopify 移动端的未来

我们在 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 上实现某个功能，反之亦然

帮助开发者快速上手，并在自己主技术栈之外的领域有效贡献

通过共享的规格说明、测试和审查检查点，大幅降低了维持平台间功能对齐的成本

原生开发仍然意味着要在两个平台上构建和维护软件，这项成本并未消失。改变之处在于，智能体现在能够完成足够多的实现、转换、测试和审查工作，使其不再是 2020 年那样的决定性因素。

React Native 应用可以很快。我们的应用就是如此。我们做出这一改变，是因为智能体降低了共享实现带来的优势，而为每个平台单独构建的优势依然存在。原生开发让我们更贴近平台能力和第一方工具，代码与平台之间的框架和依赖层更少。

我们 React Native 开源库的未来

在我们介绍迁移方式之前，我们希望确保这次过渡干净利落。从一开始，我们就想回馈 React Native，让它变得更好。我们发布的开源库已成为各自类别中的首选。我们感谢社区的热烈反响，并承诺确保这是一次平稳、无意外的过渡。

React Native Skia

Shopify 将继续赞助该项目直至 2026 年底，此后 William Candillon 将继续推进。他将在未来几个月内 fork 该仓库，并以新名称开始发布这个库。过渡完成后，原仓库将被归档。我们会沿途发布更新，让每个人都有充足的时间迁移。如果你的应用依赖这个库，请考虑赞助它。

FlashList

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

Restyle

Restyle 的用户群比我们其他库要小，因此我们将归档这个仓库。我们会让它继续运行到 2026 年底，之后停止维护。欢迎任何人 fork 并接手推进，如果有团队愿意接手，我们会协助完成交接。

我们如何迁移

Shopify 有几款大型应用（Shopify、Shop、Point of Sale、Inbox）。全球数百万商家和买家每天都依赖它们来谋生，并从他们喜爱的品牌购买心仪的产品。

我们曾在逐步迁移到原生（棕地）与从零重建（绿地）之间反复权衡。过去我们迁移到 React Native 时，对一些最大的应用选择了棕地方式，因为重写它们需要数年时间，而且在重写进行期间我们不得不停止发布新功能。

然而，这一次全新开发（greenfield）成为了明显的赢家，原因如下：

大语言模型擅长以 React Native 版本为参照，用 Swift 和 Kotlin 构建功能

它给了我们一张白纸，让我们能够以最佳方式重建，不受此前任何约束

我们的原型表明，我们重建这些应用的速度可以比在编码智能体出现之前快得多

Shop 应用经常在应用商店购物类榜单中名列前茅，是第一个被迁移的。在 AI 的辅助下，团队仅用 12 周就从概念验证走到了完全重建的原生应用并发布到应用商店。我们在这里深入撰写了这次迁移。

Shopify 应用的迁移（我们最大的应用，拥有 300+ 屏幕、主屏幕与锁屏小组件、Apple Watch 应用、复杂功能、Siri Shortcuts 等）也在进行中，将于今年晚些时候发布。我们其余的应用也将很快迁移。

防止粗制滥造

把大语言模型直接指向 React Native 代码库，试图一次性在原生端实现相同功能，这很诱人，但行不通。即使你让它事先尽可能多地收集信息，将其固化为规格说明、任务文件，然后再实现，最终你得到的仍是大量无法维护、无法发布的代码。

为了解决这个问题，我们构建了一个名为 Helix 的系统，它采用了一种更为渐进的方式。它不指望第一次输出就是正确的，而是构建了一个循环：不完美的尝试根本无法向前推进，直到它变成一个好结果。

开发者将 Helix 指向一个屏幕。Helix 读取 React Native 代码，并提出一系列检查点（将工作切分成小的、有序的片段），这些检查点可以在几分钟内完成审查。然后，它逐个检查点地构建：每一个检查点都必须通过测试证明其行为，在视觉审查中与运行中的应用保持一致，经受住两名对抗性代码审查员的检验，并在提交、开启下一个检查点之前获得人工的点头认可。每次审查的反馈都会被记住，因此随着迁移的推进，这个循环会变得更加自主。

Helix 使用 Swift 和 Kotlin 重建 Shopify 移动应用中的一个屏幕

这种方法效果极佳，让我们能够以极短的时间重建我们的应用。

实现快速反馈循环

对模拟器的智能体控制一直是个瓶颈。我们发现自己不断地照看它们，因为它们无法可靠地构建、测试和迭代。我们构建了工具，让智能体能够自主复现 bug、修复它们并验证修复，但它既慢又脆弱。React Native 的热模块重载有助于缓解这一情况，但并未解决它，因为模拟器控制本身就很慢。这主要是因为依赖无障碍树或截图来获取应用状态、执行操作并验证结果。智能体可以在几秒内完成代码修改，但测试输出却要花上几分钟。这使得迭代极其缓慢且依赖人工。无论模型多好，如果它无法快速测试自己的工作，那都无济于事，而这在移动端尤其困难。

我们正在通过设计同时服务于人类和智能体的应用架构来解决这个问题。这里的核心原则是，业务逻辑应完全与 UI 解耦，并能够在桌面端无头运行。然后我们通过 CLI 将其提供给智能体，让它们能够在毫秒级而非分钟级进行迭代，而无需涉及模拟器。

使用 CLI 浏览应用并执行操作

CLI 让智能体能够检查应用状态、在不同板块之间导航并执行操作，全程无需触碰 UI。这实现了极快的反馈循环，并让智能体能够一次自主工作数小时。

当需要与模拟器交互时，CLI 可以通过远程模式连接到它们，并通过命令驱动 UI，而无需检查布局或无障碍树。这带来了极快的性能和端到端测试。

这是实时的（未加速）

接下来是什么

我们将在整个过程中借助 AI，把所有移动应用迁移到 Swift 和 Kotlin。Shop 已经作为完全原生应用发布，Shopify 应用正在进行中，其余的也将很快跟进。我们推进得很快，但并不是靠降低标准。每一次重建都必须达到或超越人们如今所期望的性能、稳定性、无障碍性和产品质量。这不仅仅是把同样的应用用不同语言重写一遍。我们重建它们，是为了让人类和智能体都能快速理解、测试和修改它们。

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

我们会分享一路上的所学，包括对 Helix、我们面向智能体的架构，以及我们如何用智能体构建移动应用的深入探讨。我们曾坦诚分享从 React Native 中学到的东西，我们也打算对这次转型同样坦诚。

这是我们承接过的最具雄心的移动工程项目之一。如果你想帮助打造 Shopify 下一代移动应用，我们正在招聘移动工程师、基础设施工程师，以及在 AI 与软件工程交叉领域工作的开发者。

致谢

原生开发对现在的 Shopify 来说是正确选择，但 React Native 在 2020 年对 Shopify 来说也是正确选择。那次成功之所以成为可能，全靠那些让它运转起来的人。

Meta

感谢 Meta 的 React Native 团队，他们是这个框架出色的管理者，倾听我们的反馈，并在多年间与我们紧密合作。React Native 今天能有如此显著的进步，正是因为你们在架构、性能、工具链和社区上的投入。

William Candillon

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

Software Mansion

感谢你们在 Reanimated 上的所有工作，感谢你们倾听我们的反馈，并帮助我们解决了应用中一些最棘手的动画和性能问题。

Shopify 工程师们

数百名工程师为采用 React Native 做出了贡献，包括迁移我们的应用、构建共享基础、提升性能、维护集成，以及回馈生态系统。你们中的许多人重新成为了初学者，挑战了长期以来的假设，并在持续为商家和买家交付的同时，让这次转型取得了成功。谢谢你们。

React Native 社区

感谢所有使用我们开源库、贡献代码、报告问题、质疑我们决策并分享所学所得的人。你们的贡献和反馈，包括那些犀利的反馈，让我们的工作变得更好。

过去六年中积累的工具、经验教训和人际关系，将继续塑造我们在 Shopify 构建移动应用的方式。我们深深感谢每一位参与其中的人。