Shopify: coding agents made native mobile cheaper than React Native sharing

ID: e0bea100
原文链接: https://shopify.engineering/back-to-native
作者: Mustafa Ali / Shopify Engineering
日期: 2026-09-10
平台: blog
来源类型: article
标签: coding-agents, mobile, react-native, swift, kotlin, verification, field-note
质量评分: 4/5
抓取时间: 2026-09-11T15:54:30+00:00
抓取状态: ok

中文导读

Shopify 解释为什么在 2020 年 all-in React Native 后重新转向 Swift/Kotlin 原生移动端：coding models 让双端各写一遍的成本结构改变Shop App 在 AI 辅助下 12 周完成原生重写并上架；他们用 Helix 把迁移拆成 checkpoint，每步必须通过测试视觉审查两个 adversarial reviewer 和人工确认更关键的是 headless 业务逻辑 CLI 与 remote mode，把 agent 验证从慢 simulator 交互转成毫秒级反馈回路

为什么值得关注

Shopify 的转向不是RN 死了，而是 coding agent + 可验证环境正在侵蚀跨平台框架最核心的省工假设

English summary

Shopify says React Native remains good, but LLM agents changed one core assumption behind the 2020 decision: maintaining parity across Swift and Kotlin no longer costs what it used to. Its Shop app moved from PoC to a native app in 12 weeks, while Helix enforces checkpointed tests, visual review, adversarial reviewers and human approval. The deeper lesson is agent-addressable architecture: decouple business logic from UI and expose a CLI so agents can iterate without slow simulator loops.

图片

抓取内容（opencli-first）

Native is now the future of mobile at Shopify (2026)

原文链接: https://shopify.engineering/back-to-native

blog|Mobile

Native is now the future of mobile at Shopify

Coding agents changed what it costs to build mobile apps twice. Here’s why Shopify is moving from React Native back to Swift and Kotlin.

Published on Sep 10, 2026

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.

[

](https://www.youtube-nocookie.com/watch?v=SEtglzYpQ80 "YouTube video")

_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.

[

](https://www.youtube-nocookie.com/watch?v=jOIv_VC1Plk "YouTube video")

_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.

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.

by Mustafa Ali

Published on Sep 10, 2026

by Mustafa Ali

Published on Sep 10, 2026

• 9 minute read

Development Introducing Ruvy Developer Tooling Building a ShopifyQL Code Editor

Apps Shopify’s platform is the Web platform Development The Engineering Story Behind Flex Comp

Obsidian evidence excerpt

Shopify 回原生：coding agent 把双端成本模型翻过来了

1/ 9 月 10 日，Shopify 工程博客发文《Native is now the future of mobile at Shopify》：移动端从 React Native 回到 Swift 和 Kotlin。这不是普通的框架选型反转。2020 年他们 all-in React Native，2025 年 1 月还写「RN 的未来一片光明」，20 个月后把结论翻过来，理由只有一个：coding models 变强之后，「同一个 feature 双端各写一遍」的成本结构变了。HN 一天冲到 926 分 626 评论（13:40 CST 实时）。

https://shopify.engineering/back-to-native

2/ 先看交付了什么。Shop App 在 AI 辅助下 12 周从 PoC 到原生重写上架，配套文章给出完整数字：冷启动 iOS 从 3200ms 降到 2466ms（-23%），Android 从 4433ms 降到 2233ms（-50%）；session stability 从 99.5% 拉到 99.95%，崩溃会话减少约 10 倍；Android 包体砍 109MB（-37%），release 构建时间降约 75%；Android 端滚动 feed 到 120FPS，「到目前为止几乎没做优化」。主 Shopify App（300+ screens、widgets、Apple Watch、Siri Shortcuts）迁移中，年内发。

https://shopify.engineering/shop-app-migration

3/ 这件事不能读成「React Native 死了」，Shopify 原文也明说了：RN apps 可以很快，他们自己的就很快，RN 仍是优秀框架。翻的是 2020 年的账：当年选 RN 的三个理由（不用同一 feature 写两遍、开发者跨端工作、少追平台对齐）都成立，但 coding agent 出现后，「写两遍」的成本大幅下降，而平台能力、第一方工具、更少的框架层重新变重。核心假设变了，就从头重估——这是工程判断，不是站队。

4/ 值得抄的是迁移门禁，Shopify 做了两层。第一层是 Helix：把每个 screen 拆成有序的小 checkpoint，每个 checkpoint 必须过测试、visual review、两个 adversarial code reviewer、人类点头，才能 commit 进下一段；不指望第一次输出就对，而是让不完美的尝试无法前进，直到变成好结果。第二层在 Shop App 那篇：迁移工作流做成 Pi coding agent 的 extension，plan 的 acceptance 绑定内容 hash，改了 plan 就作废之前的审批——审批始终挂在真实被审过的实现计划上。

5/ 第二个可抄的是反馈回路设计。simulator 一直是 agent 的瓶颈：代码几秒改完，验证要几分钟，因为读状态靠 accessibility tree 和截图。Shopify 的解法是把业务逻辑从 UI 完全解耦，能在桌面 headless 跑，再包一个 CLI 给 agent——毫秒级迭代，不碰 simulator，能自主跑几个小时。需要真机 UI 时用 remote mode 命令式驱动。Shop App 那篇还加了 Tardis：给 agent 结构化访问运行中 app 的事件、日志、状态，还能对 RN 版和原生版在命名 checkpoint 上截图 + 抓事件窗口做 parity 对比。对做 Android 性能的同学，这就是把 trace/事件做成 agent 可读接口的同一件事。

https://shopify.engineering/shop-app-migration

6/ HN 评论区已经把反方立场摆全了。netshade 做过同规模 RN→原生迁移，认为工作量大头在 2026 年 1 月前就完成了，「LLM 让迁移变便宜」的叙事不准确；sashank_1509 拿数字怼：Shopify 3000 工程师 vs Chrome 2008 年约 60 人、GTA5 制作组 150 人，认为他们的工程观点不该被当权威；ernsheong 判断这是「以为 AI 让复杂度免费」，不会 age well；iBelieve 注意到全文没提 Kotlin Multiplatform，双端是靠 shared specifications 和 tests 对齐，不是共享代码。另一方 atonse 用 codex 一晚上迁完自家 15-20 屏的小 app，lmf4lol 把 750 个单测的 Electron app 丢给 Astra 写原生 iOS 版。正反样本都在，值得读完再下判断。

https://news.ycombinator.com/item?id=49643982

7/ 边界：① Shop App 12 周是单公司样本，token 花费未公开；② Shopify 是大团队 + 高频大 app，小团队没有他们的验证基础设施，直接弃 RN/Flutter 是误读；③ 这不是全行业判决——Meta 仍是 RN 的主导维护方，Shopify 自己的 FlashList（每周约 200 万下载）继续修 critical compatibility 并在找长期维护方，RN Skia 资助到 2026 年底后由原作者 fork，Restyle 年底停维护；④ iOS 的 23% 和 Android 的 50% 冷启动提升是同一公司两平台的自比，不能横比。

8/ 我的判断：跨平台框架的第一性卖点是「省掉双端重复劳动」，这个卖点正被 coding agent 的「参考实现 + 可验证环境」组合侵蚀——agent 能拿 iOS 版当参考实现 Android 版（反向也行），双端对齐靠 shared specs/tests/review checkpoints 维持，而不是靠共享代码。当验证基础设施成熟，平台能力、性能上限、第一方工具的权重回升。对移动团队，该从这两篇里搬走的不是「回原生」这个结论，是 Helix 的 checkpoint 门禁、plan-hash 审批、headless CLI 反馈回路这三件基础设施——它们在任何技术栈上都成立。

9/ 对 Android 工程师的具体读法：① 这条不改变 RN/Flutter 在中小团队的性价比判断，但把「原生太贵」的溢价压低了，选型时值得重新算账；② Jetpack Compose 与 SwiftUI 的声明式 UI 是迁移成本变低的暗线——Shopify 明说 RN 工程师靠熟悉的声明式概念就能上手双端原生；③ 包体、构建时间、稳定性的数字说明 agent 写的原生代码没有付质量税，前提是门禁在场；④ 如果你做性能优化，Tardis 这种「给 agent 结构化访问运行时状态」的思路可以直接借鉴到自家工具链。

https://shopify.engineering/back-to-native https://shopify.engineering/shop-app-migration https://news.ycombinator.com/item?id=49643982