AI Is Breaking the Cross-Platform Tradeoff

A few weeks ago, Shopify announced that it had rebuilt the Shop app from React Native to native Swift and Kotlin. That caught my attention, mostly because Shopify has been one of the companies most closely associated with React Native over the past few years. They invested in it, contributed to the ecosystem, and used it in major production apps.

At first, this looks like another “company moves back to native” story. But I think the more interesting part is why they did it.

The answer has a lot to do with AI.

For years, the biggest advantage of cross-platform development was fairly obvious: building the same product twice is expensive. If you go fully native, you need to implement and maintain the iOS version in Swift and the Android version in Kotlin. React Native, Flutter, and similar frameworks reduce that duplication by allowing a large part of the product to live in one shared codebase.

That tradeoff made sense even if cross-platform came with some friction. You might have to deal with framework-specific bugs, wait for support for new operating system APIs, or drop into native code when something didn’t fit the abstraction. In many cases, those problems were still cheaper than having two teams build the same feature twice.

AI is starting to change that calculation.

Shopify says coding agents played a major role in making their native migration practical. The Shop team went from an early proof of concept to shipping native versions of the app in roughly 12 weeks. They also built internal tooling to help agents translate React Native screens into native implementations while keeping architectural rules and quality constraints in place.

That matters because one of the assumptions behind cross-platform development is that duplicated code also means duplicated human effort. If a developer builds a feature on iOS, and an agent can produce most of the equivalent Android implementation, the relationship between those two things becomes weaker.

You still have two codebases, but you may no longer be paying twice the implementation cost.

And once that happens, native development becomes more attractive. You get direct access to platform APIs, native tooling, native UI frameworks, and fewer abstractions between your app and the operating system. Historically, those advantages were often not enough to justify the extra engineering cost. With AI doing more of the repetitive implementation work, they might be.

That does not mean React Native is dying. In fact, React Native itself is probably technically stronger today than it has ever been. Its architecture has improved significantly, the ecosystem is mature, and for many teams the productivity benefits are still obvious.

A small startup with three engineers is unlikely to suddenly maintain completely separate iOS and Android products just because coding agents exist. React Native also has another major advantage: teams already familiar with React and TypeScript can move into mobile development without rebuilding their entire engineering stack.

So I don’t think cross-platform frameworks are going away. What may change is the point at which they stop being the obvious choice.

A few years ago, even a large engineering organization could look at two native codebases and decide that the duplication simply wasn’t worth it. In a world where agents can generate, port, test, and maintain a significant amount of that code, the cost becomes easier to justify.

There is also a broader idea here that goes beyond mobile development. Software engineering has spent decades trying to reduce the amount of code humans have to write. We created shared libraries, reusable components, code generators, cross-platform frameworks, and countless abstractions partly because writing and maintaining code was expensive.

But code itself is becoming cheaper to produce.

That doesn’t make architecture less important. It probably makes architecture more important. If generating implementation becomes easy, the difficult parts become defining behavior, setting constraints, designing good interfaces, writing meaningful tests, and making sure all these generated implementations behave consistently.

Maybe that is where cross-platform development eventually moves.

Instead of trying to run the same code everywhere, we may define the product once and let tooling generate the best implementation for each platform. The shared layer would no longer necessarily be JavaScript or Dart. It could be a specification, a set of components, tests, design tokens, API contracts, and product behavior that agents translate into Swift, Kotlin, web code, or whatever platform comes next.

For years, the promise was “write once, run everywhere.”

The next version might be closer to “define once, generate everywhere.”

Shopify’s migration doesn’t prove that this is where the industry is heading. But it is a pretty interesting signal that the economics behind cross-platform development are starting to change.

References

• Shopify Engineering — “Migrating Shop app from React Native to native”September 10, 2026shopify.engineering/shop-app-migration
• Shopify Engineering — “Native is now the future of mobile at Shopify”September 10, 2026shopify.engineering/back-to-native
• Shopify Engineering — “Helix: The internal tool powering our Shopify app’s native migration”September 21, 2026shopify.engineering/helix
• React Native — “About the New Architecture”reactnative.dev/architecture/landing-page
• React Native — “React Native 0.87”August 11, 2026reactnative.dev/blog/2026/08/11/react-native-0.87