Shopify Went Back to Native. Does That Mean Your App Should Too?

Shopify is moving parts of its app away from React Native and back to native Swift and Kotlin. That's a big deal in mobile development circles, because Shopify was one of the loudest advocates for React Native for years. If a company with that much engineering weight is walking some of it back, it's worth asking what it actually means for anyone else weighing up how to build a mobile app.

The short answer: it doesn't mean cross-platform is broken. It means Shopify hit the specific point where native's advantages outweighed the convenience of one codebase, for one part of a very large, very demanding app. Most businesses never get near that point. But the decision is a useful prompt to check you're choosing for the right reasons, not just because it's what you heard about last.

What React Native is actually good at

React Native lets you write one codebase in JavaScript or TypeScript and ship it to both iOS and Android, with native components underneath rather than a web view pretending to be an app. For most business apps, that's the right call. Booking systems, portals, internal tools, anything with forms, lists, notifications and a bit of camera or location access, all work well in React Native. You get one team, one release cycle, and changes that land on both platforms at the same time.

I built Patch, a bookings and payments app for trades, this way. There's no reason a plumber checking his diary needs two separate native codebases maintained in parallel. The app doesn't need frame-perfect animation or deep access to platform-specific APIs. It needs to be reliable, fast enough, and cheap enough to maintain that changes actually get made when the business needs them.

Where native starts to win

Shopify's case is different because of scale and what the app actually does. Large ecommerce apps push hard on things like camera performance for barcode scanning, complex list rendering with huge datasets, animations that need to feel instant, and tight integration with platform features that get updated every iOS and Android release. At that scale, the bridge between JavaScript and native code, even the newer versions with less overhead, becomes something you have to actively manage rather than ignore. There are a few signals that suggest native is worth the extra cost:

• You need heavy use of the camera, AR, background processing, or hardware sensors, and performance is part of the product.
• You're building something with genuinely complex, custom UI that doesn't map cleanly onto standard components.
• You've got the budget and the roadmap to justify maintaining two codebases properly, rather than one team stretched across both.
• Platform-specific features (widgets, deep OS integrations, the newest APIs) are core to what you're offering, not a nice extra.

If none of those apply, going native mostly buys you double the maintenance cost and double the places a bug can hide, for a benefit your users probably won't notice.

The mistake is picking based on trend, not need

What's easy to miss in stories like Shopify's is that the decision is contextual. A company running one of the biggest apps in the world made a call about specific parts of specific screens. It's not a verdict on cross-platform development as a category. But because it's a well-known name, it tends to get repeated as a general rule: "React Native is out, go native." That's not useful advice for a business building its first app. The better question isn't "what's the industry doing", it's "what does this app actually need to do well, and what can I afford to maintain in two years' time." A native app with no one available to keep both codebases current is a worse outcome than a cross-platform app that gets updated regularly.

What this means if you're weighing up an app

If you're at the stage of scoping a mobile app for your business, start from the use case, not the technology. Ask what the app has to do reliably, who's using it, and how often you expect to change it once it's live. A field service app used by a handful of staff to log jobs and take payment is a very different proposition to a consumer product competing on speed and polish. Most business apps, internal tools, booking systems, client portals, sit firmly in the first category. Cross-platform gets you there faster and keeps ongoing costs sane, because one person or one small team can maintain the whole thing without splitting attention across two skill sets.

If your app genuinely needs native-level performance or deep platform integration, that's a real cost to plan for from the start, not something to bolt on later. Either way, the decision should come from what the app needs to do, not from which company changed direction this month.

I work through this with clients at the scoping stage, before any code gets written, on my app development page. It's usually a shorter conversation than people expect, because for most business apps the answer is clear once you look at what's actually required.