Shopify is moving its apps from React Native to Swift and Kotlin. Here are the real numbers, what drove the move, and whether it applies to your app.
Is Shopify moving away from React Native a reason to leave it?
Not by itself. Shopify announced on September 10, 2026 that it is rebuilding its mobile apps in Swift and Kotlin because coding agents made building for two platforms cheaper, while saying React Native apps can be fast and the framework is excellent. Its conditions differ from most teams', so treat the news as a prompt to re-check your own numbers, not as a verdict (Shopify Engineering).
This guide separates what Shopify said from what the headlines said, shows the measurements from its rebuilt Shop app and their caveats, explains why the economics differ for a smaller team, and gives you a checklist for deciding. It also states the case for going native fairly, because parts of it are strong.
Disclosure: Groooh builds React Native apps, so we have a stake in this debate. We have tried to present Shopify's case accurately, including the numbers that favor native.
Choosing between React Native and native, or weighing a migration? Send us your app and constraints and we will give you an honest recommendation. Request a free 30-minute architecture review
What did Shopify actually announce?
Shopify announced it will rebuild all of its mobile apps in Swift and Kotlin, starting with the Shop app, because AI coding agents made building for two platforms cheaper. It did not say React Native is slow or broken.
| What | Detail |
|---|---|
| Announced | September 10, 2026, by Mustafa Ali, Shopify's Head of Mobile |
| Decision | Rebuild every mobile app in Swift and Kotlin using AI, from scratch, with the React Native apps as the reference |
| Stated reason | Coding agents reduced the advantage of sharing implementation across platforms, while the advantages of building for each platform remain |
| What it did not say | That React Native is slow. Shopify says its apps are fast and the framework remains excellent |
| Cost it admits | Building and maintaining two platforms still costs more. Shopify says the cost has not disappeared, only that it no longer decides the question for Shopify |
| Shop app | First to move: a proof of concept to a published native app in 12 weeks, built by a core group of six engineers |
| Shopify app | The largest app, with 300+ screens, widgets, and an Apple Watch app, due later in 2026 |
| Tooling it built | Helix for checkpoint-by-checkpoint migration, a debugging tool called Tardis, and a headless command line so agents can test logic without a simulator |
| Open-source libraries | React Native Skia continues under its creator in a fork, FlashList (about 2 million downloads a week) needs new stewards, and Restyle is archived |
Sources: Native is now the future of mobile at Shopify and Migrating Shop app from React Native to native, both Shopify Engineering. Mustafa Ali's title is from The Pragmatic Engineer.
Cost was not the only reason in the post. Shopify also says native keeps it closer to platform capabilities and first-party tooling, with fewer framework layers in between, and that during its React Native years it spent significant effort on performance work, improving framework foundations, and keeping up with framework and dependency updates. It judged those tradeoffs acceptable until agents changed the math.
What did Shopify measure after rebuilding the Shop app?
Shopify's rebuilt native Shop app beat its React Native predecessor on five of the six measures it published, with the biggest gaps in Android build time, crashing sessions, and Android cold start. The numbers are real, but they come from Shopify, from a first version, and from an app that had not yet adopted React Native's New Architecture (Shopify Engineering).
| METRIC | RN | NATIVE |
|---|---|---|
| Android release build time | 100 | 25 |
| Crashing sessions | 0.5 | 0.05 |
| Android cold start | 4433 | 2233 |
| Android app size | 293 | 184 |
| iOS cold start | 3200 | 2466 |
| iOS app size | 67 | 68 |
Hover over a bar to see the React Native and native values behind it. Shopify describes the stability change as a 10x reduction in crashing sessions, and notes that the Android release build shrank by 109 MB while the iOS build stayed about the same size.
Four caveats before you generalize from these numbers.
- They are Shopify's own measurements, and a first version. Shopify calls the native app a baseline it expects to improve, so the gap may widen.
- The React Native Shop app had not adopted the New Architecture. Shopify says other apps that did gain it saw about 10 percent faster startup on Android and 3 percent on iOS, and some complex screens got slower until tuned (The Pragmatic Engineer). The comparison is native against an older React Native setup, not against the current one.
- It was not a like-for-like rebuild. Shopify retired some screens and streamlined others during the migration, so part of the improvement may come from a simpler app.
- React Native results were already strong elsewhere in Shopify. In its 2025 review Shopify reported screen loads under 500 ms at the 75th percentile and over 99.9 percent crash-free sessions in its React Native apps (quoted by The Pragmatic Engineer). Shop's own history was lower, at 99.5 percent or higher.
Shopify also says native expertise stayed essential. Generated code could meet feature requirements while adding duplication, architectural drift, or performance problems, so the team relied on linting, tests, static analysis, performance checks, and review (Shopify Engineering).
Does Shopify's reasoning apply to your app?
Probably less than the headlines suggest. Shopify's conclusion rests on a large organization, a custom AI migration system, mature React Native apps to copy from, and platform features such as widgets and a watch app. Most small teams lack several of those.
| Factor | Shopify | Most startups and product teams |
|---|---|---|
| Scale | Several large apps, with 300+ screens in the biggest | One or two apps with far fewer screens |
| Platform-specific features | Home and lock screen widgets, an Apple Watch app, complications, Siri Shortcuts | Mostly forms, lists, feeds, checkout, and dashboards |
| Team | A large engineering organization with a six-engineer core group for the Shop rebuild | One small team that builds both platforms together |
| AI tooling | A custom migration system, a debugging tool, a headless command line, and a shared test suite that validates logic on both platforms | Off-the-shelf coding assistants without a custom pipeline |
| A reference to port from | Mature React Native apps that agents used as the specification | Often no existing app to copy from |
| Native expertise | Existing platform engineers, and Shopify says native expertise stayed essential | Often no dedicated iOS or Android specialists |
| Parity enforcement | A process built to keep both apps identical at all times | A shared codebase gives parity by default |
The Shopify column comes from Shopify's posts and The Pragmatic Engineer. The right-hand column is our assessment, not data, and your team may differ.
Shopify's reasons for choosing React Native in 2020 were to build features once, let developers work across platforms, and stop chasing parity. All three still describe what a small team gains. What changed for Shopify is that its scale and tooling let it buy those benefits another way.
Does AI make building two native apps cheap enough?
AI lowers the cost of a second codebase, but it does not remove it, and Shopify's own post says so. The savings are largest when you already have a mature app to port from, strong native engineers to review the output, and tests that prove both apps behave the same.
What AI changes, according to Shopify
- Agents can build a feature on Android using the iOS version as a reference, and the reverse.
- Developers can contribute outside their main platform, because agents help them ramp up.
- Shared specifications, tests, and review checkpoints cut the cost of keeping both platforms in step.
- A proof of concept took one engineer one week, and the full Shop rebuild took 12 weeks.
What AI does not change
- You still own two codebases. Every feature still has two implementations to test, review, release, and debug. Shopify says that cost has not disappeared (Shopify Engineering).
- One-shot translation does not work. Shopify says pointing a model at the React Native code and asking for the native version produces a large amount of unmaintainable code that cannot ship. It built Helix to force each small step through tests, a visual match, two adversarial reviews, and human approval.
- Native expertise still matters. Generated code can meet requirements while adding duplication, architectural drift, or performance problems (Shopify Engineering).
- Parity needs enforcement. A shared codebase gave Shopify parity by default. Native requires a development and release process built to enforce it, including one shared test suite that validates the logic in both Swift and Kotlin (The Pragmatic Engineer).
AI helps React Native teams too. The same agents speed up TypeScript work, so the comparison is not native with AI against React Native without it. Gergely Orosz makes a similar point: writing native apps is easier than before, but so is writing React, Flutter, and Kotlin Multiplatform apps (The Pragmatic Engineer).
A middle path is getting attention. Kotlin Multiplatform shares business logic across platforms while keeping the interface native. Shopify's own architecture goal is related: business logic decoupled from the interface so it can run headless and be tested by agents. That idea does not depend on the framework, and it works in a React Native codebase too.
What does the native side get right?
The native case is stronger than React Native advocates often admit. It rests on five points, and a fair reading of Shopify's post supports them.
- Fewer layers means more control. Shopify says native keeps it closer to platform capabilities and first-party tooling. Gergely Orosz notes that a well-written native app naturally outperforms its React Native equivalent, because there is one less abstraction between your code and the platform (The Pragmatic Engineer).
- The measurements favor native. On Shopify's numbers, the native Shop app starts faster, crashes less, and is smaller on Android. The caveats above matter, but the direction is clear.
- Framework upkeep is a real cost. Shopify names time spent on performance work, improving framework foundations, and keeping up with updates and dependencies. Its own open-source libraries are now changing hands, which is a risk for any team that relies on Skia, FlashList, or Restyle.
- There is precedent. Airbnb adopted React Native in 2016 and moved back to native about two years later, citing performance (The Pragmatic Engineer).
- Platform features arrive first on native. Widgets, watch apps, and new system APIs are first-party on native. React Native reaches them through libraries or native modules.
It is also not the end of React Native. RedMonk's analysis says it will watch whether other large, well-resourced companies share Shopify's willingness to maintain several native codebases (RedMonk). One company's decision is evidence, not a trend, until others follow.
Can you keep one shared UI and write native code only where it matters?
Yes. React Native lets you write Swift and Kotlin and call it from your shared TypeScript. These native modules, and native views, are how teams get platform-specific features without giving up one UI for iOS and Android. It is the middle path between all React Native and all native, and Shopify described its approach this way before this change (The Pragmatic Engineer).
How native modules work. A native module is platform code that your JavaScript can call. In React Native's Turbo Native Modules, you write a typed TypeScript specification, a tool called Codegen generates the native interfaces, and you implement them in Kotlin or Java on Android and Objective-C++ on iOS (React Native docs). The Expo Modules API lets you write native modules and views in Swift and Kotlin with less boilerplate, supports the New Architecture, and performs comparably to Turbo Modules (Expo docs). Both use React Native's JavaScript Interface instead of the old bridge.
| What you need | Approach | Notes |
|---|---|---|
| A platform API or third-party SDK with no React Native library | Native module | The Expo docs give the example of an analytics SDK your company mandates |
| A specialized platform control or view | Native view component | Renders a real platform view inside your React tree |
| Home screen widgets and watch apps | Native extension beside the app | Community libraries such as react-native-widget-extension help wire it up |
| Performance-intensive code and long-running background work | Native module or native service | Shopify's 2025 review named these as places where it still used native code |
| Forms, lists, feeds, checkout, and dashboards | Shared React Native UI | One implementation for both platforms |
Sources: React Native docs, Expo docs, and The Pragmatic Engineer for Shopify's 2025 list.
What you gain. Most of the app stays one codebase with one team, and you get platform-quality behavior exactly where the product needs it. The Expo docs note that most developers never write native code, because libraries already cover many cases such as camera, maps, and haptics.
What it costs. Each native module has two implementations, one per platform, so you need Swift and Kotlin skills for those pieces and you maintain them across operating system releases. Keep the number of modules small and the boundary between JavaScript and native code narrow.
Where AI helps most. Small, well-defined native modules are the kind of work coding agents handle well, and Shopify says agents help developers contribute outside their main platform (Shopify Engineering). That makes the hybrid path cheaper than it was, without adding a second UI codebase. Our starting point with clients is shared UI first, native modules for the specific features that need them, and measurement before anything is replaced.
What should you do now if your app is on React Native?
Do not rewrite because of a headline. Re-test your original decision with your own data, and fix the risks Shopify's news does expose. This checklist takes a few days.
- Write down why you chose React Native, and check whether each reason still holds
- Measure your own cold start time, crash-free session rate, and app size on a mid-range Android phone
- Check your React Native version and whether you run the New Architecture. Shopify saw only modest startup gains from it, so measure before you assume a benefit
- List every dependency on Shopify's libraries, because React Native Skia is moving to a fork, FlashList needs new stewards, and Restyle is archived after 2026
- List the platform features you will need in the next 12 months, such as widgets, a watch app, or deep system integration, and mark which need native modules
- Separate business logic from the interface so it can run and be tested without a simulator
- Add tests that run headless, so coding agents and your team get fast feedback
- Price the alternative: get a written estimate for the native path and compare it with your yearly cost of React Native upkeep
- Set a review date every six months, because these tradeoffs are moving quickly
When is going native the right call?
Staying on React Native is the wrong advice in five situations.
- Your product is built around platform features. Widgets, watch apps, Siri Shortcuts, advanced camera pipelines, AR, and deep system integration are first-party on native and reached through native modules in React Native.
- You already run strong iOS and Android teams. If both teams exist and the budget supports them, the main saving from a shared codebase is smaller.
- You have Shopify-like resources. A mature app to port from, native engineers to review output, and a test suite that proves parity make the AI-assisted native path realistic.
- You have measured a real shortfall. If cold start, crash rate, or smoothness on your target devices misses your goals after tuning, switch the parts that miss, or the whole app if the gap is broad.
- Upkeep is costing more than sharing saves. If framework upgrades and unmaintained dependencies take a large share of your engineering time, price the alternative honestly.
Even then, you do not have to choose one or the other. Many teams keep React Native for most screens and write native code for the few that need it, which is how Shopify itself described its approach before this change (InfoQ).
Frequently asked questions
Is Shopify abandoning React Native?
Shopify is moving its own mobile apps to Swift and Kotlin, starting with the Shop app. It is not declaring the framework dead: its post calls React Native an excellent framework and thanks the React Native team at Meta, Software Mansion, and the community (Shopify Engineering).
Why is Shopify leaving React Native?
Shopify says coding agents made building for two platforms cheaper, which reduced the advantage of sharing code. It also says native keeps it closer to platform capabilities and first-party tooling, with fewer framework layers between its code and the platform (Shopify Engineering).
Was React Native too slow for Shopify?
Shopify says React Native apps can be fast and that its own are. Its rebuilt native Shop app still started 23 percent faster on iOS and 50 percent faster on Android, with caveats: the old app had not adopted the New Architecture, and some screens were simplified during the rebuild (Shopify Engineering).
Should my startup rewrite in native?
Not because of this news. Re-test your decision with your own measurements first. Native makes sense if your product depends on platform features such as widgets or a watch app, if you already run separate iOS and Android teams, or if you have measured a performance gap you cannot tune away.
Does AI make native cheaper than React Native for small teams?
AI lowers the cost of a second codebase but does not remove it. You still test, review, release, and debug two apps. Shopify needed custom tooling and native engineers to make its rebuild work, which most small teams do not have (Shopify Engineering).
What happens to Shopify's React Native libraries?
React Native Skia continues under its creator, William Candillon, in a fork published under a new name, with Shopify sponsoring through the end of 2026. FlashList, with about 2 million weekly downloads, will receive critical compatibility fixes while Shopify seeks long-term stewards. Restyle is archived after 2026 (Shopify Engineering).
What are native modules in React Native?
Native modules are Swift, Kotlin, Java, or Objective-C++ code that your JavaScript can call, so a mostly shared React Native app can still use platform-only features. React Native's version is the Turbo Native Module, and Expo offers a simpler Expo Modules API (React Native docs, Expo docs).
Get an honest recommendation for your app
Send us your app, your team, and your constraints and we will tell you whether React Native, native, or a mix fits. If native is the better answer for you, we will say so. Request your free architecture review
Related reading
- React Native App Development Cost in 2026: What Founders Should Actually Budget
- React Native vs Flutter in 2026: The Final Verdict for Enterprise Scaling
- Claude Code vs Cursor: Why We Switched Our Agency's CLI for 2026 Projects
- The React Native 0.86 Upgrade Path: How to Bypass the Breaking Changes of Legacy Modules
Sources
Sources reviewed October 17, 2026. Shopify's migration is ongoing, so confirm details against its latest posts.
- Native is now the future of mobile at Shopify, Shopify Engineering: the decision, reasons, Helix, open-source library plans
- Migrating Shop app from React Native to native, Shopify Engineering: 12-week rebuild, measurements, lessons
- Why has Shopify dropped React Native?, The Pragmatic Engineer: New Architecture results, shared test suite, Airbnb precedent, Kotlin Multiplatform
- Shopify Drops React Native for Swift and Kotlin as AI Changes Cross-Platform Development Tradeoffs, InfoQ: Shopify's earlier native-and-React-Native approach
- Shopify returns to native, and what that says about rewrites in the agentic era, RedMonk: community reaction and what to watch
CEO and Head of Engineering at Groooh. A seasoned systems architect with over a decade of experience guiding venture-backed startups and growth teams from 0-to-1 MVP delivery to scale. Specializes in cross-platform mobile architectures, resilient cloud infrastructure, and applied agentic AI integrations that drive measurable commercial impact.
Ready to build your next breakthrough product?
Let’s collaborate on your architecture roadmap, MVP sprint, or full product build with our senior team.
