A few weeks ago I was on a call about a new mobile app and the usual question came up. Flutter, React Native or native? Five years ago that was an easy one for me, depending on budget. One codebase, one team, half the cost, ship it.
Now I always say go native for both platforms.
Then Shopify published their post about moving back to Swift and Kotlin, and I felt a lot less crazy. It kinda feels like the natural next step.
What Shopify actually said
Quick recap for anyone who missed it.
Shopify went all in on React Native in 2020, in a post called React Native is the Future of Mobile at Shopify. In January 2025 they doubled down, saying the future of the framework was bright and they were staying. Then, in September 2026, they published Native is now the future of mobile at Shopify.
React Native did not get worse. They say their apps are fast and the framework is still good. What changed is one of the assumptions the 2020 decision was built on.
The assumption was simple: building the same feature twice costs twice as much.
That single idea is the foundation of every cross-platform pitch ever made. Take it away and the whole argument falls apart.
Why the math changed
Coding agents got good. Not “autocomplete my for loop” good. Good enough that you can hand one an iOS screen and ask it to build the Android version using the iOS code as the reference.
You still need a mobile engineer who knows the platform. Someone who can look at generated SwiftUI and say the state is living in the wrong place, or that this list is going to stutter on an older device, or that nobody does navigation like that on Android. An agent will happily hand you something that compiles, runs, and is wrong in a way you only find out three months later. So the agent does not get a blank canvas. It gets the spec, the conventions of the repo, the folder structure it has to respect, and a definition of done it cannot negotiate with.
Then it gets a harness. Tests it has to pass. Visual checks against the real screen. Lint and format rules that fail the build. Small checkpoints instead of one giant PR nobody wants to review. A human approving each one before the next starts.
That is the part worth sitting with. The expensive thing about native was never the second language. It was doing the same thinking twice, then keeping both versions in sync forever.
Now you write the spec once, the tests once, the review checklist once. Two agents run in parallel, one in Swift, one in Kotlin. You review both (I’m being minimalistic here.)
The work does not disappear. It just stops being the deciding factor.
Shopify rebuilt the Shop app from scratch and shipped it to both stores in 12 weeks. That app sits at the top of the shopping category. Twelve weeks.
And they did not just point an agent at the old code and hope. They built a system called Helix that breaks a screen into small checkpoints, makes each one prove itself with tests and a visual comparison against the running app, runs it past two adversarial reviewers, then waits for a human to say yes before moving on.
They also decoupled business logic from the UI so it can run headless on a desktop, with a CLI agents can drive. Agents write code in seconds but testing on a simulator takes minutes, so that gap was the real bottleneck. Fixing it let agents work on their own for hours.
That is engineering, not vibe coding.
The tax nobody puts in the slide deck
Here is the part I have felt personally, over and over.
Apple announces something at WWDC. Your client watched the keynote and wants it in the app. With Swift, you open Xcode and start. With cross-platform, you wait.
You wait for the framework to support it. Then for a wrapper library. Then for the one maintainer of that library, who has a day job and a family, to merge the PR. Sometimes you fork it yourself, and now you own a fork forever.
Think of it like a translator in the room. A good translator, honestly. But you are always one step behind the conversation, and you can only say what they know how to say.
Native gives you the API on day one. Widgets, Live Activities, Watch app, Siri, the new camera stuff, whatever ships. It is just there.
The Shopify part that really got me
Shopify is not a small shop trying to save money. They have hundreds of mobile engineers and effectively unlimited budget for this.
They also wrote the libraries the rest of the ecosystem depends on. FlashList does around 2 million downloads a week and is the default way to render a fast list in React Native. React Native Skia changed what animation looked like in that world. Restyle, same team.
Now Restyle is getting archived, they are shopping FlashList around for someone to take over long term, and Skia is being forked out to William C., the person who created it.
If the company building the tools everyone else relies on runs the numbers and walks away, that is not a small opinion. That is the people closest to the problem telling you the tradeoff stopped paying.
And if they could not keep up, what exactly is a five-person team going to do?
So what do I actually do on Monday?
A few things I would do Today if I were starting a mobile project:
- Write the spec once, review it hard, and treat it as the real shared codebase. The spec and contracts are what both platforms now have in common, instead of the UI layer.
- Share logic, not pixels. Kotlin Multiplatform for networking (if applicable), models, and business rules. SwiftUI and Compose for everything the user touches.
- Design the app so agents can test it on top of MCP so they can see it. Pull business logic out of the UI, make it runnable without a simulator, give it a CLI. Fast feedback beats a smarter model.
- Review like it matters, because it does. Several parallel agents coding, testing, reviewing, and shipping.
Am I saying delete your React Native app
No. Please do not do that because of a blog post.
If you have a shipping app, a team that knows the stack, and users who are happy, migrating might be a bad idea. Shopify did not migrate for vibes either. They prototyped first, rebuilt real parts of their biggest apps, and only then made the call.
But if you are starting something new in 2026 and the main reason you are picking cross-platform is cost, that reason is a lot weaker than it was last year.
What I am taking from this
- Cross-platform solved a cost problem. Agents solve that same problem now without putting a layer between you and the platform.
- Native means you never wait on someone else’s release schedule to use what Apple and Google just shipped.
- The skill that matters now is writing a clear spec and building a review loop you trust, not typing the same screen twice in two languages.
I still think React Native, or Flutter or other Cross-Platform tools, were the right call sometimes in 2020. I defended it in plenty of meetings when it made sense (financially, commercially, and sometimes technically). I am just not sure what is left to defend in 2026.
If building it twice costs almost the same as building it once, why would you build it in the middle?