Shopify Ditches React Native: Was It Ever Worth It?

The React Native vs native development debate has been raging since Facebook open-sourced the framework in 2015, but for a while, Shopify seemed like the argument-ender. Here was a company with serious engineering muscle, serious scale, and a serious commitment to the framework. They didn't just adopt React Native. They built React Native Skia. They built Flash List. They wrote the tooling the rest of the community depended on. They published blog post after blog post evangelizing the approach.

And now they're walking it back.

Shopify has confirmed it is moving its mobile engineering toward Swift and Kotlin, platform-native development, after years of betting the farm on a shared JavaScript layer. The engineers who cheered their 2021 "React Native is the future" posts are watching the company quietly reverse course. The engineers who stayed skeptical are not surprised.

What Shopify Actually Built (and Why It Mattered)

To understand why this reversal stings, you have to appreciate how all-in Shopify went. This wasn't a startup trying React Native because it was cheap. Shopify was a publicly traded company with hundreds of mobile engineers choosing to standardize on a JavaScript bridge between their product and the operating system.

Their reasoning was sound on paper. One codebase, shared logic, faster iteration, easier hiring from the larger JavaScript and TypeScript talent pool. The React Native architecture at the time made some of this genuinely compelling. And Shopify's open-source contributions were real. Flash List solved a legitimate performance problem with React Native's default FlatList. React Native Skia brought GPU-accelerated 2D graphics to the framework. These weren't toy projects.

But here's the part the evangelism glossed over: Shopify was also spending significant engineering resources working around React Native's limitations. Every library they built was, in part, a workaround. Flash List exists because FlatList is too slow at scale. Skia integration exists because the default rendering pipeline can't handle complex graphics. When your adoption story requires that you also build the missing half of the framework yourself, that's a signal worth paying attention to.

The JavaScript Bridge Was Always the Problem

The core tension in React Native vs native development has never really been about developer experience or hiring or code sharing. It's about the bridge.

For most of React Native's life, JavaScript and native code communicated over an asynchronous bridge. Every interaction that needed to cross that boundary introduced latency. On a fast device with a simple UI, you'd never notice. On a mid-range device with a complex list, an animated gesture, or a camera integration, you absolutely would.

Meta introduced the New Architecture (Fabric renderer, JSI, TurboModules) to address exactly this. JSI eliminates the bridge in favor of direct JavaScript-to-native bindings. Fabric makes rendering synchronous. The New Architecture is now the default in React Native 0.74. This is genuinely meaningful progress.

So why is Shopify still leaving?

Because the New Architecture solves the bridge problem but doesn't solve the abstraction problem. You're still writing JavaScript that describes what native components should do. You're still depending on a layer of translation between your intent and the operating system's capabilities. When Apple ships a new SwiftUI API or Google ships a new Compose component, native developers get it immediately. React Native developers wait for the community to wrap it, or they write their own native module, which means they're writing Swift and Kotlin anyway.

The 'Write Once, Run Anywhere' Promise Has a Long History of Overpromising

This is not a new story. Java applets promised it. Adobe AIR promised it. Xamarin promised it. Cordova and PhoneGap promised it. Flutter is currently promising it (and facing its own questions about long-term Google commitment). Every generation of cross-platform tooling arrives with the same pitch: stop paying for two codebases.

The pitch is seductive because the cost is real. Maintaining separate iOS and Android codebases does mean duplicated effort. It does mean coordinating two teams. It does mean slower feature parity. Nobody is arguing that native development is free.

But the hidden cost of cross-platform frameworks is also real, and it tends to show up later, when you're debugging a platform-specific rendering bug through three layers of abstraction, or when you need a capability that the framework doesn't expose yet, or when you're trying to profile a performance problem and your tools are fighting the JavaScript runtime instead of talking to Instruments or Android Studio directly.

The tradeoff people miss is that you don't eliminate the native complexity. You delay encountering it, and then you encounter it at the worst possible time, when you're trying to ship.

The React and TypeScript Ecosystem Deserves Nuance Here

Before this turns into a blanket indictment of JavaScript on mobile, some precision is warranted.

React and TypeScript are genuinely excellent for web. The component model maps well to the DOM. The TypeScript type system catches real bugs. The ecosystem is mature in ways that matter for web frontend and full-stack development. None of that is in dispute.

The problem is that mobile is not the web. iOS and Android are not browsers. The assumptions that make React productive on the web (a single rendering engine, a well-specified layout model, a platform that was designed to run JavaScript) don't transfer cleanly to mobile. You're not running React in its native environment. You're running it as a guest in someone else's house, and the host has opinions.

This is why the React Native vs native development question is genuinely different from "should I use React for my web app." For web, React is a strong default for most teams. For mobile, the calculus is more complicated, and Shopify's reversal is evidence of that complication at scale.

What the Engineering Community Is Saying

The reaction in engineering circles has been predictably split.

One camp sees this as validation of everything they've been saying for years. Native is native. The platform vendors build for Swift and Kotlin. The best performance, the best tooling, the best access to new APIs all live there. Cross-platform is a compromise, and at some point, the compromises accumulate.

The other camp points out that most apps are not Shopify. Most apps don't have the traffic, the complexity, or the engineering budget that makes native's advantages worth the cost. For a startup shipping an MVP, for a team of five trying to cover iOS and Android simultaneously, React Native or Flutter might be entirely the right call. The framework's limitations are real but so is the cost of two separate teams.

Both camps have a point. The mistake is treating either position as universally correct.

What's harder to argue with is the specific pattern Shopify represents: a company that went all-in, built significant infrastructure on top of the framework, and still concluded that the long-term trajectory pointed back toward native. That's not a story about a team that didn't try hard enough or didn't understand the framework. That's a story about accumulated friction at scale.

My Take: Cross-Platform Mobile Frameworks Are a Liability Disguised as Velocity

Here's where I'll be direct. The "write once, run anywhere" promise for mobile is not a productivity strategy. It's a debt instrument. You borrow velocity now and pay interest later, in debugging time, in native module wrappers, in performance investigations that require understanding both JavaScript and platform internals simultaneously.

For teams with limited resources and simple apps, that debt might be worth taking on. The interest payments stay manageable. But for any team building a mobile product that is central to the business, that will need to evolve with platform capabilities, that will be used by millions of people on a range of devices, the case for native development keeps getting stronger the longer you run the numbers.

Shopify's decision isn't shocking to engineers who have been on the native side of this argument for years. What's notable is that it's Shopify making it. This is the company that had every incentive to make React Native work. They had the engineering talent, the resources, and the institutional investment. If they've concluded that the abstraction cost isn't worth it at their scale, that conclusion carries weight.

The broader lesson is about abstraction layers in general. Every layer you add between your code and the platform buys you something and costs you something. Sometimes the buy is worth it. Sometimes, especially when the platform itself is the product, you want to be as close to the metal as possible.

Swift and Kotlin are genuinely good languages. SwiftUI and Jetpack Compose have closed a lot of the ergonomic gap that made native development feel painful compared to React's component model. The argument that native development requires twice the work is less true than it was in 2015 when React Native launched. The platforms have gotten better. The frameworks have gotten better. The tooling has gotten better.

Meanwhile, the fundamental architectural constraints of React Native haven't changed as much as the community hoped they would. The New Architecture is real progress, but it's progress toward catching up to where native already was.

Where This Leaves Full-Stack and Frontend Teams

If you're a full-stack JavaScript developer who has been leaning on React Native to cover mobile, Shopify's move is worth taking seriously. It doesn't mean you should immediately rewrite your React Native app in Swift and Kotlin. Most apps aren't at Shopify's scale, and most teams aren't in a position where the tradeoffs tip that decisively toward native.

But it does mean you should be honest with yourself about what you're trading. React Native gives you JavaScript familiarity and code sharing. It costs you platform proximity and, at sufficient scale, performance headroom. That's a real tradeoff, and pretending it isn't one is how teams end up surprised three years into a project.

The engineers who build the best mobile products tend to be the ones who understand both sides of the React Native vs native development question and make a deliberate choice rather than defaulting to whichever technology they already know. Shopify knew React Native as well as anyone. They made their choice.

That should tell you something.