Shopify announced on 10 September 2026 that it is moving its mobile apps off React Native and rebuilding them in Swift and Kotlin. Six years earlier it went all-in on React Native, and as recently as January 2025 it said the framework's future was bright. React Native has not got worse since then. It has never been in better shape. What changed is that AI coding agents made building the same app twice cheap enough that the strongest argument for sharing one codebase stopped holding.
That matters to anyone commissioning an app, because the cost argument that pushed nearly every agency towards cross-platform between 2015 and 2024 is the exact argument Shopify has just retired.
Here is what Shopify actually said, how the industry ended up on cross-platform in the first place, the problem agencies were really trying to fix, and how we think the choice should be made in 2026.
We're Hatchet, a Perth team that has been building mobile and web apps for 10+ years, across both native and cross-platform. This is our read on it.
What did Shopify actually announce?
Shopify is rebuilding its mobile apps natively, in Swift for iOS and Kotlin for Android, using AI agents throughout. The Shop app has already shipped as a fully native rebuild. The main Shopify app, with 300+ screens, widgets, an Apple Watch app and Siri Shortcuts, is underway. The rest follow.
The detail worth reading twice: the Shop app went from proof of concept to a fully rebuilt native app in the app stores in 12 weeks. Not a port. A greenfield rebuild of an app that sits at the top of the shopping category.
Shopify's own write-up is candid about why. It picked React Native in 2020 for three reasons: stop building the same features twice, let developers work across the stack, and spend less time chasing feature parity. All three held for six years. Then one assumption underneath them changed.
In their words, by late 2025 the models were "capable of making us question whether building software twice still meant doing twice the work". They prototyped, rebuilt core parts of their biggest apps in Swift and Kotlin, and found agents could implement an Android feature using the iOS version as the reference, and the reverse. The cost of two codebases did not disappear. It stopped being the deciding factor.
The ecosystem consequences are real. React Native Skia gets Shopify sponsorship to the end of 2026 before moving to a new maintainer, FlashList is looking for long-term stewardship, and Restyle is being archived.
Why did agencies go cross-platform in the first place?
Agencies went cross-platform because a client would ask for an iOS app and an Android app, and the budget only ever covered one.
Before 2015, that meant two separate builds. An iOS app written in Objective-C, later Swift. An Android app written in Java, later Kotlin. Two codebases, two sets of tests, two QA passes, two release processes, and two sets of annual platform changes to keep up with. For a small agency quoting a fixed price, iOS plus Android was close to double the number, and clients did not see why.
So the industry tried to route around it. PhoneGap and Cordova wrapped a web app in a native shell. It was cheap and it shipped, and users could tell. Appcelerator Titanium and Xamarin took their own runs at it, with Xamarin putting C# on both platforms.
React Native arrived in January 2015 as a preview at React.js Conf and was open-sourced that March for iOS, with Android following in September. The pitch landed because it was different from the wrapper approach: JavaScript drove real native UI components rather than a web view pretending to be an app.
For agencies, the maths was obvious. One codebase. One team. Web developers who could contribute to a mobile app without learning two new languages. Business logic written once. Flutter arrived as the other serious contender in late 2018 with a different trade-off, painting its own pixels rather than using platform components.
It was never a clean sweep. Airbnb sunset React Native in June 2018 after roughly two years, citing a mix of technical and organisational problems, and put its effort back into native. Meta doubled down instead, starting the New Architecture rewrite in 2018, shipping it as the default in React Native 0.76 in October 2024, and handing React and React Native to the new React Foundation under the Linux Foundation in October 2025.
What problem were agencies really solving?
Not "which framework is best". The real problem was building a commercial-ready app on two platforms for something close to the price of one.
Cross-platform genuinely fixed part of that. One team shipping to both stores, one set of business rules, one design system, features landing on both platforms in the same sprint. For most of the app work agencies quote on, a booking app, a membership app, a field-data app, a customer portal, that was the right call and we would make it again for the era it was made in.
It just moved some of the cost rather than removing it. The parts that came back to bite:
- Anything genuinely platform-specific still needed native code. Bluetooth, background location, camera pipelines, secure payment flows, widgets and watch apps all meant writing a native module anyway, with a JavaScript wrapper on top.
- A dependency upgrade treadmill. A cross-platform app is a framework plus a stack of community libraries, and the maintenance bill arrives every year whether the app changed or not.
- Library abandonment risk. Critical functionality often sat behind a package maintained by one person on the weekend.
- Performance work at the edges. Lists, animations and heavy screens needed tuning that a native build would not have needed.
- Debugging across two layers. When something broke, the question of whether it was your code, the framework or the platform cost real hours.
The saving was real. It was never the 50% the pitch implied, and a slice of it was spent again later on maintenance. Shopify's post says the same thing in polite language, calling the performance and upgrade work "acceptable tradeoffs" that the benefits outweighed.
What changed in 2026?
Coding agents changed the price of doing the work twice.
Look closely at what "building it twice" actually involved. Same product decisions, same business logic, same screens, same states, same edge cases, expressed in a second language against a second SDK. A large share of it is translation with a known reference implementation sitting right there. That is the kind of work current models are unusually good at.
Shopify's findings were that agents could build a feature on one platform using the other platform as a reference, help developers contribute outside their primary stack, and hold parity through shared specifications, tests and review checkpoints. The second codebase stops being a second project and starts being a second output.
Two caveats in their post are worth more than the headline.
The first is about quality. Pointing a model at a React Native codebase and asking it to one-shot a native version does not work. Shopify were blunt: you end up with "a huge amount of unmaintainable code that can't be shipped". They built a system called Helix that breaks a screen into small ordered checkpoints, where each one has to prove itself with tests, match the running app in a visual review, survive two adversarial code reviewers, and get a human's approval before the next one starts.
The second is about feedback loops. Agents write code in seconds and then wait minutes for a simulator to tell them whether it worked. Shopify's answer was to decouple business logic from the UI so it runs headlessly on a desktop, then expose it to agents through a CLI. Iteration in milliseconds instead of minutes.
Neither of those is a prompt. They are engineering investments, and they are the reason the 12-week rebuild is believable.
Does this mean React Native is dead?
No. React Native is in the best technical shape of its life, and most apps being commissioned this year should still be built on a shared codebase.
It is worth being precise about whose decision this is. Shopify has hundreds of mobile engineers, apps with 300+ screens, watch apps, widgets and lock screen complications, and a platform team that can afford to build its own agent orchestration system before the migration even starts. The cost of two codebases stopped mattering to them because they could invest their way around it.
A business shipping its first app on a fixed budget is in a different position. One codebase, one team and one set of tests is still usually the fastest way to something real in both stores. What has actually changed is that native is no longer automatically the expensive option, so it deserves to be on the table for projects where it used to be ruled out on price alone.
Native or cross-platform: how should you choose in 2026?
Start from what the app has to do, not from what is trending. A rough guide to how we weigh it up:
| What you are building | Usually the better fit | Why |
|---|---|---|
| First version of a product, standard interface, fixed budget | Cross-platform | One codebase gets you into both stores fastest |
| Heavy device features: Bluetooth, background location, camera, widgets, watch | Native | Fewer layers between your code and the platform APIs |
| Staff app for a fleet of company-issued devices | Native, single platform | There is no second build to pay for |
| A mobile version of an existing web product | Cross-platform | Shared logic, shared team, shared design system |
| Animation and interface performance is the product | Native | No framework or dependency layer to tune around |
| A long-lived product with an in-house team taking it over | Native | Fewer moving dependencies to maintain over five years |
The questions we put to clients before any of this gets decided are simple. What does the app need from the device? Who maintains it in three years? Is one platform enough for version one? Those answers move the decision far more than the framework debate does. If you want to talk it through against a real scope, that is what our Perth app developers do in the first conversation.
How we're approaching it at Hatchet
We use AI in our own work where it makes us faster, and a senior developer reviews everything that ships. AI-assisted, not vibe-coded. That distinction is the whole point of Shopify's checkpoint system, and it is the difference between an app that demos well and an app that handles real data, real users and real money for years.
Practically, three things change for us.
We treat the stack decision as a decision, not a default. Picking a framework once in 2018 and quoting from that cost model ever since is how agencies end up recommending the wrong thing confidently. Stack choices get made during the fixed-fee Design Phase, while the scope is being defined and before anyone writes production code.
We hold the same engineering steps regardless of what wrote the first draft of the code. Architecture designed by a senior developer, tests, code review, security checks, staging, accountable hosting. Faster typing does not remove any of them.
And we no longer assume a second native codebase is out of reach for a mid-sized budget. It often still is. But it is now a costing exercise rather than an automatic no, and that is a meaningful change for app development work in Australia.
The bigger pattern
The interesting part of Shopify's post is not Swift and Kotlin. It is this line: "We don't hold on to a decision just because it was successful at the time."
Stack decisions have a shelf life. The cross-platform consensus was built on a cost model from an era when a developer could only be in one language at a time. That model has moved, so the conclusions built on it have to be re-tested. Some will survive. This one did not, at least at Shopify's scale.
For anyone buying software, the takeaway is not "go native". It is to ask your development partner when they last re-examined their default, and what changed their mind. An agency that cannot answer that is quoting your project from an old spreadsheet.