原生开发如今已成为 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 构建移动应用的方式。我们深深感谢每一位参与其中的人。
Native is now the future of mobile at Shopify
We decided to go all-in on React Native back in 2020, and that bet has been extremely successful. We saved a ton of time building features just once, enabled developers with no mobile background to contribute to our apps, and freed ourselves from constantly chasing feature parity.
In January 2025, I wrote that the future of React Native was bright and that Shopify planned to keep investing in it. That was true based on what we knew then. React Native was working well for us, and it remains an excellent framework. But since then, coding models have gotten dramatically better, and for our apps and our team, building the same feature in Swift and Kotlin no longer carries the cost it used to.
We don’t hold on to a decision just because it was successful at the time. When a core assumption changes, we’re willing to go back and ask whether it’s still the right call. LLMs changed one of the core assumptions behind our 2020 decision, so we reevaluated our mobile stack from first principles.
What we found led us back to native.
Why switch back to native
We decided to switch from native to React Native in 2020 for three reasons:
- Stop building the same features twice
- Allow developers to work across the stack
- Spend less time chasing feature parity and more time shipping value
React Native consistently delivered these benefits. We found ourselves spending a significant amount of time and resources on optimizing performance, improving key foundational areas in React Native, and keeping up with framework updates and external dependencies, but these were acceptable tradeoffs. The benefits of using React Native far outweighed the investments we had to make in these areas.
Shopify has been using LLMs to build software since 2021 (one year before ChatGPT!). Initially, we used them to implement features, investigate and fix bugs, and review code. As the models improved, so did the complexity of the work we trusted them to take on. By late 2025, they were no longer just helping us write code faster. They were capable of making us question whether building software twice still meant doing twice the work.
We decided to reevaluate our mobile tech stack and started prototyping to see whether our technology choices still held up. We rebuilt several core parts of our biggest apps in Swift and Kotlin using LLMs and were surprised by how well it worked. Agents:
- Could implement a feature on Android using the iOS version as a reference, and vice versa
- Helped developers ramp up and contribute effectively outside their primary stack
- Dramatically reduced the cost of maintaining parity between platforms through shared specifications, tests, and review checkpoints
Native still means building and maintaining software on two platforms, that cost has not disappeared. What changed is that agents can now do enough of the implementation, translation, testing, and review work that it’s no longer the deciding factor it was in 2020.
React Native apps can be fast. Ours are. We are making this change because agents have reduced the advantages of sharing implementation, while the advantages of building for each platform remain. Native keeps us closer to platform capabilities and first-party tooling, with fewer framework and dependency layers between our code and the platform.
The future of our React Native open-source libraries
Before we get into how we’re migrating, we want to make sure we do this transition cleanly. From the beginning, we wanted to contribute back to React Native to make it better. We’ve published open-source libraries that have become the top choice in their respective categories. We’re grateful for the incredible reception from the community and are committed to making sure this is a smooth transition with no surprises.
React Native Skia
Shopify will continue sponsoring this through the end of 2026, and William Candillon will continue working on it beyond that. He will fork the repo in the coming months and start publishing the library under a new name. The original repo will be archived when this transition is complete. We’ll post updates along the way so that everyone has ample time to migrate. If your app relies on this library, please consider sponsoring it.
FlashList
This library gets ~2M downloads/week and has become the default way to render high-performance lists in React Native. Given how important it is for the ecosystem, Shopify will continue to fix critical issues that break compatibility. We’re currently in discussions with several companies about taking on long-term stewardship of FlashList. If you’re interested, reach out to me here.
Restyle
Restyle has a smaller user base than our other libraries, so we're archiving this repo. We'll keep it working through the end of 2026, then stop maintaining it. Anyone is welcome to fork it and take it forward, and we'll help with the handover if a team wants to pick it up.
How we’re migrating
Shopify has several large apps (Shopify, Shop, Point of Sale, Inbox). Millions of merchants and buyers around the world rely on them every single day to earn their livelihood and buy products they want from the brands they love.
We debated between gradually migrating to native (brownfield) versus rebuilding them from scratch (greenfield). In the past when we migrated to React Native, we picked the brownfield approach for some of our biggest apps, as it’d take years to rewrite them and we’d have to stop shipping new features while the rewrite was in progress.
However, this time greenfield emerged as a clear winner for the following reasons:
- LLMs are good at building features in Swift and Kotlin using the React Native version as reference
- It gives us a clean slate to rebuild in the best way possible without any of the previous constraints
- Our prototypes showed that we could rebuild these apps substantially faster than was possible before coding agents
The Shop app, which is regularly at the top of the list in the shopping category in the app stores, is the first to be migrated. Assisted by AI, the team was able to go from a proof of concept to a fully rebuilt native app published in the app stores in just 12 weeks. We’ve written about this migration in depth here.
The migration of the Shopify app (our biggest with 300+ screens, home & lockscreen widgets, Apple Watch app, complications, Siri Shortcuts, etc.), is also underway and will ship later this year. The rest of our apps will be migrated soon.
Preventing slop
It’s tempting to just point an LLM to the React Native codebase and try to one-shot the same features in native, but it doesn’t work. Even if you ask it to gather as much information as it can up front, freeze that into specs, task files, and then implement it, you end up with a huge amount of unmaintainable code that can’t be shipped.
To solve this problem, we built a system called Helix that takes a more gradual approach. It doesn't expect the first output to be correct, and builds a loop where an imperfect attempt simply cannot move forward until it becomes a good result.
The developer points Helix at a screen. Helix reads the React Native code and proposes a sequence of checkpoints (small, ordered slices of the work) that can be reviewed in minutes. Then, checkpoint by checkpoint, it builds: each one must prove its behavior with tests, match the running app in a visual review, survive two adversarial code reviewers, and get a human's nod before it's committed and the next one starts. Feedback from every review is remembered, so the loop gets more autonomous as the migration progresses.
Helix rebuilding a screen in the Shopify mobile app using Swift and Kotlin
This approach has been working extremely well and is allowing us to rebuild our apps in a fraction of the time.
Enabling fast feedback loops
Agentic control of simulators has been a bottleneck. We found ourselves constantly babysitting them as they couldn’t reliably build, test, and iterate. We built tooling to allow agents to reproduce bugs, fix them, and verify the fix autonomously but it was slow and brittle. React Native’s hot module reload helps the situation but it doesn’t solve it, due to simulator control being slow. This is primarily due to reliance on the accessibility tree, or screenshots to get the state of the app, take actions, and verify results. Agents can make code changes in seconds, but it takes them several minutes to test the output. This makes iterating extremely slow and manual. It doesn’t matter how good the model is if it can’t test its work quickly, which is especially difficult on mobile.
We’re fixing this by designing our app architecture to work for both humans and agents. The core principle here is that business logic should be completely decoupled from the UI and be able to run headlessly on desktop. We then make it available to agents via a CLI that allows them to iterate on it in milliseconds instead of minutes without involving simulators.
Navigating the app and performing actions using the CLI
The CLI allows agents to inspect the state of the app, navigate between different sections, and perform actions all without needing to touch the UI. This enables extremely fast feedback loops and allows agents to work autonomously for hours at a time.
When simulator interaction is needed, the CLI can connect to them via a remote mode and drive the UI via commands without having to inspect the layout or the accessibility tree. This enables blazing-fast performance and E2E tests.
This is real-time (not sped up)
What’s next
We are going to migrate all our mobile apps to Swift and Kotlin using AI throughout the process. Shop has already shipped as a fully native app, the Shopify app is underway, and the rest will follow soon. We’re moving quickly, but not by lowering the bar. Every rebuild must meet or exceed the performance, stability, accessibility, and product quality people expect today. This isn’t just the same apps rewritten in different languages. We’re rebuilding them so both humans and agents can understand, test, and change them quickly.
The migration isn’t the finish line. Success means our teams can deliver better experiences for merchants and buyers faster than before. We’ll measure that through product velocity, app quality, and how much work agents can complete autonomously.
We’ll share what we learn along the way, including deeper dives into Helix, our agent-addressable architecture, and how we’re building mobile apps with agents. We were open about what we learned from React Native, and we intend to be just as open about this transition.
This is one of the most ambitious mobile engineering projects we’ve taken on. If you want to help build the next generation of Shopify’s mobile apps, we’re hiring mobile engineers, infrastructure engineers, and developers working at the intersection of AI and software engineering.
Acknowledgements
Native is the right choice for Shopify now, but React Native was the right choice for Shopify in 2020. That success was only possible because of the people who made it work.
Meta
Thank you to the React Native team at Meta for being excellent stewards of the framework, listening to our feedback, and working closely with us over the years. React Native is substantially better today because of your investments in its architecture, performance, tooling, and community.
William Candillon
Thank you for creating React Native Skia and taking it much further than any of us imagined. You redefined what was possible for graphics and animation in React Native, and we’re excited to see where you take it next.
Software Mansion
Thank you for all your work on Reanimated, for listening to our feedback, and for helping us solve some of the hardest animation and performance problems in our apps.
Shopify engineers
Hundreds of engineers contributed to adopting React Native, migrating our apps, building shared foundations, improving performance, maintaining integrations, and contributing back to the ecosystem. Many of you became beginners again, challenged long-held assumptions, and made the transition successful while continuing to ship for merchants and buyers. Thank you.
The React Native community
Thank you to everyone who used our open-source libraries, contributed code, reported issues, challenged our decisions, and shared what you learned. Your contributions and feedback, including the spicy kind, made our work better.
The tools, lessons, and relationships built over the past six years will continue to shape how we build mobile apps at Shopify. We’re deeply grateful to everyone who was part of it.