Shopify's engineering team argues that despite years of deep investment — hiring core contributors, adopting the New Architecture and Hermes — startup time regressed on mid-tier Android, memory pressure hurt older devices, and the bridge tax never fully disappeared. Their conclusion is that at flagship scale touching tens of millions of users, the framework's ceiling is real and moving to Swift/Kotlin is the pragmatic answer.
By submitting the Shopify post with the framing 'moves back to Native from React Native,' the submitter surfaces the argument that even the most well-resourced RN shop couldn't sustain the framework for its crown-jewel apps. The 389-point score signals broad community agreement that this is a meaningful signal about RN's limits.
Shopify cites Live Activities, predictive back gestures, and newer camera/ML APIs as capabilities that consistently ship first on native and take months (or never) to reach RN. For apps that need to be competitive on platform-native UX, waiting on the framework ecosystem is a strategic liability.
The editorial emphasizes that Shopify isn't killing RN internally — smaller internal tools, admin surfaces, and experiments continue to ship on the framework. The migration is scoped specifically to flagship apps where performance regressions become support tickets, suggesting RN remains viable for lower-stakes contexts.
Shopify — the same company that in 2020 published a widely-cited blog post declaring React Native its future, and that shipped its merchant app, Shop app, and Point of Sale on the framework — has begun migrating those flagship apps back to native Swift and Kotlin. The engineering post, titled bluntly "Back to Native," landed on Hacker News with 389 points and predictable arguments in the comments.
Shopify isn't killing React Native internally; it's pulling the crown-jewel apps off it. Smaller internal tools, admin surfaces, and experiments will continue to ship on RN. But the apps that touch tens of millions of merchants and buyers — the ones where a 200ms cold-start regression shows up in support tickets — are going home to the platforms.
The stated reasons are unglamorous and specific. Startup time on mid-tier Android hardware was drifting the wrong way. Memory pressure on older devices was forcing the team to fight the JS runtime for headroom the OS wanted back. New iOS and Android capabilities — Live Activities, predictive back gestures, the newer camera and ML APIs — kept landing first in native and arriving in RN months later, if at all. And the bridge tax, even after the New Architecture and Hermes, never quite went to zero.
The interesting thing about this post isn't that a big company is leaving a cross-platform framework. That happens every year. Airbnb famously did it in 2018. What's interesting is *who* is doing it and *when*.
Shopify was not a fair-weather RN adopter. They hired core contributors. They invested in the ecosystem. Their engineers wrote some of the most-cited posts on scaling RN in production. If any enterprise team had earned the right to make the framework work at scale, it was this one. When your most invested advocate quietly rebuilds the flagship in Swift, that's not a framework failure — it's a signal about where the ceiling actually is.
And the ceiling isn't where the discourse usually places it. React Native works fine for the app most teams are actually building: a handful of screens, some forms, a list, a detail view, push notifications, maybe a camera flow. The apps that hit RN's ceiling are the ones with real-time data streams, complex gesture-driven UI, tight memory budgets on the low end, and a platform-features release cadence they can't afford to lag. Point of Sale hardware integrations. Barcode scanning that has to work on a five-year-old Android tablet in a warehouse. Live inventory dashboards where a dropped frame is a bug report.
The HN thread surfaced the usual counter-arguments, and the strongest one is worth taking seriously: a lot of native-migration stories are really *team* stories. When your RN codebase is a mess, rewriting it in Swift feels like a rebirth — but so would rewriting it in RN with better discipline. The honest version of Shopify's post is that they built two native teams anyway to handle the platform edges, and at some point the JS layer stopped paying for itself. If you already need iOS and Android specialists on staff to ship the hard parts, the cross-platform value proposition inverts.
The other reaction worth engaging with came from RN core folks pointing out that the New Architecture, the Fabric renderer, and Hermes have closed most of the gaps Shopify cites. That's mostly true — for apps that adopted them cleanly on a green field. It is much less true for a five-year-old codebase with a long tail of legacy native modules, custom bridges, and third-party libraries that haven't been migrated. The migration cost of *staying* on RN, in other words, was not zero for Shopify either.
If you're on React Native today and shipping a normal product app, nothing here is a signal to rewrite anything. The framework's sweet spot — small-to-medium apps, teams that can't justify two mobile hires, product surfaces where the platform-native feel is a nice-to-have rather than a differentiator — hasn't moved. Expo in particular has quietly become one of the best DX stories in mobile, and for a startup shipping v1, RN + Expo is still probably the correct default.
If you're at the scale where you're arguing about frame budgets, cold-start percentiles at P95 on Android Go devices, or when the Live Activities API is going to land in a third-party wrapper, Shopify's post is a useful permission slip. The calculus at that scale is different: you already employ people who know the platforms deeply, your product cares about the last 10% of feel, and the marginal cost of a second native codebase is smaller than it looks because you're already writing native modules for the hard stuff anyway. The question stops being "can RN do this?" and becomes "is the JS layer paying rent?"
A more practical takeaway for teams in the middle: audit which of your screens actually benefit from being cross-platform. It's common to find that 70% of a codebase is genuinely shared logic — forms, lists, network — while the 30% that hurts is a small number of high-touch surfaces (camera, video, complex gestures, background tasks) that are basically native modules with a JS wrapper on top. Shopify's implicit argument is that once that ratio inverts on your hottest paths, the framework is costing more than it saves. That's a measurable thing, not a taste thing. Instrument it before you argue about it.
The cross-platform pendulum swings on a roughly five-year cycle, and we're due for a swing. Kotlin Multiplatform is quietly showing up in a lot of these conversations now — it shares business logic without trying to own the UI, which is exactly the split Shopify's post implicitly endorses. Flutter continues to eat the design-driven end of the market. React Native's next chapter will probably be a slightly humbler one: a very good framework for a well-defined class of apps, not the universal mobile runtime some of its 2020-era boosters wanted it to be. That's a healthier place for it to land, and Shopify — for all the takes this post will generate — probably did the ecosystem a favor by saying so out loud.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.