Shopify's 'Back to Native' post argues that after six years on React Native, the surfaces merchants use most heavily have hit inherent limits of a JS-driven stack — cold-start latency on low-end Android, jank in complex lists, and lag behind platform releases. They're rebuilding these screens in Swift and Kotlin because the RN ceiling can't be raised further through optimization alone.
By submitting the Shopify post to HN with framing that emphasizes the 'move back' narrative, the submitter surfaces the story as a validation that cross-platform JS runtimes cannot match native for demanding production workloads. The 903-point response reflects widespread agreement that this is a significant admission from RN's most visible enterprise champion.
Shopify is careful to frame the move as surgical: only latency-sensitive screens are going native while shared business logic and less-critical views stay in JavaScript. They emphasize this is not a rip-and-replace — it's an acknowledgment that RN is the right tool for many parts of the app but not all of them, preserving the cross-platform investment where it still pays off.
The editorial argues Shopify's stated reasons — cold-start, jank, platform-release lag, New Architecture interop tax — read like a checklist every RN skeptic has been raising since 2018. What's new is that the flagship reference customer, the one Meta itself cited, is publicly conceding the ceiling exists, which reshapes the credibility landscape for the whole framework.
The editorial distinguishes two RN camps: those who use it purely for cost/velocity, and those who claim it delivers native-equivalent UX. Shopify was the flagship of the second camp, and their retreat means enterprises will find it harder to justify RN on quality grounds — the honest pitch narrows back to 'cheaper and faster to ship,' not 'as good as native.'
Shopify's engineering blog published "Back to Native," acknowledging that key surfaces of the Shopify merchant app — the ones merchants actually live in day to day — are being rebuilt in native Swift and Kotlin after roughly six years on React Native. This is not a rip-and-replace announcement. It's a targeted retreat: performance-critical screens are moving off RN while shared logic and less-latency-sensitive views remain in JavaScript for now.
The context matters. Shopify was arguably the single most credible enterprise reference for React Native, publishing multi-part case studies in 2020-2022 about migrating the entire mobile app to RN and open-sourcing tooling like Restyle, FlashList, and react-native-skia along the way. When Shopify wrote about React Native, other CTOs listened. Meta itself cited Shopify in its Product Excellence Program. The company's mobile org shipped some of the most consequential OSS in the RN ecosystem.
So the reasons Shopify gives for pulling back read like a checklist of every criticism RN skeptics have leveled since 2018. Cold-start latency on lower-end Android. Jank on complex list interactions. The chronic lag between an iOS/Android platform release and a workable RN binding. The interop tax of the New Architecture rollout. None of these are new — what's new is a Tier-1 champion saying, publicly, that they've hit the ceiling of what a JS-driven mobile stack can do for their use case.
The React Native story has always split into two camps. One camp uses RN because it's cheaper — one team, one codebase, ship faster. The other camp uses it because they believe it's genuinely competitive with native for user experience. Shopify was the flagship of the second camp, and that flag is being lowered.
That distinction is what makes this story bigger than a single engineering decision. Airbnb famously walked away from RN in 2018, and the counter-narrative for years was: "Airbnb tried it too early, the tooling wasn't there, look at Shopify." That rebuttal just got weaker. Coinbase, Discord, and Microsoft (in various pockets) have made similar reversions with less fanfare. The pattern isn't that RN doesn't work — it obviously does; Instagram, Facebook, and thousands of shipped apps prove that. The pattern is that at scale, in a product where mobile is the product, the marginal gains from a shared JS layer stop paying for the marginal costs of the abstraction.
The HN thread on the post (903 points at time of writing) surfaces the same fault line. The top comments split cleanly: RN practitioners defend the ecosystem's progress with the New Architecture, Fabric, and Hermes; native practitioners point out that "we finally fixed the fundamentals" is not a great pitch a decade in. A recurring note from ex-Shopify engineers in the thread: the company invested more in RN internals than almost any other shop and still couldn't close the gap on the surfaces that mattered most. If the team that funded FlashList couldn't make lists feel native enough, that's a data point about the ceiling, not the effort.
There's also a labor-market subtext. Over the last three years, senior mobile engineers pushed back on "we do everything in RN" job descriptions — the pipeline for platform-native talent (especially Kotlin/Compose and Swift/SwiftUI) has stayed strong precisely because the ceiling problem was widely understood by practitioners even when it wasn't public. Shopify's admission legitimizes what a lot of staff engineers have been saying in private for two years.
If you're on React Native today, this doesn't mean rip it out. It means audit the top three user-facing surfaces of your app and honestly grade them against native competitors on cold start, scroll performance, and gesture responsiveness. If any of them is a stated business priority and grades a B or worse, budget the native rebuild now — before your competitor does. The Shopify approach — hybrid, native for hot paths, RN for the long tail — is a defensible middle ground and probably the right one for most companies at scale.
If you're greenfielding a mobile product in 2026, the calculus has shifted. Kotlin Multiplatform has quietly become production-ready — JetBrains, Netflix, and McDonald's are shipping on it, and the pitch (shared business logic, native UI) is exactly the trade Shopify's now making manually. Flutter remains a real option for teams that want a single UI framework and can accept the non-native feel. React Native is still the right choice when your team is web-native and the app is a content shell, but the days of "RN by default for everything" are ending.
For engineering leaders, the deeper lesson is about how cross-platform frameworks age. The pitch is always "write once, ship twice" — but the hidden cost is that you inherit the framework's roadmap, its platform-API lag, and its abstraction leaks forever. Native is boring, but boring compounds. RN's New Architecture is a bet that the abstraction can be made lean enough to disappear; Shopify's move suggests that even when the framework does its job, the leaky moments show up in exactly the places users notice.
Expect more of these quiet reversions over the next 18 months, and expect Meta to respond with sharper positioning — likely doubling down on RN's role in content-heavy apps (Instagram, Facebook, Threads) where the JS bridge is a smaller share of the frame budget. The framework isn't dying; it's finding its actual niche, which was never "native replacement" and was always "faster iteration for apps where 60fps on a mid-range Pixel isn't the KPI." Shopify just made that boundary explicit.
We did the same thing - had 90% of it overnight. Then spent a few days in the background tweaking for polish.Our app is smaller, and has about 15-20 screens. I started at about 12:30am by giving codex a goal and it inventoried every screen based on the react native code, then created android and iOS
That Shopify employs 3,000 engineers is astounding.I was rejected after a fairly basic ML interview at Shopify and when I asked for feedback I was told someday I could become a machine learning engineer.I don’t think the interviewer read my resume or understood my responses as this was after working
As an iOS Engineer that has been fighting the battle against every C-level type who brings up the subject of a shared codebase my whole career, I feel very validated.
Sorry not sorry RN was always the wrong choice, and I've made my money shipping React since 2013. Every RN project I've had to join has been a junk show and there is no way they operate more efficiently than 2 native teams. Don't even start me on Expo. Kotlin and Swift are nice, and O
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
Numbers from GPT Astra - Shopify has 3000 engineers as of 2026- Google Chrome when released in 2008 conservatively had ~ 60 engineers.- GTA 5 in its credits had 150 software engineers. Surprising even to me who has had many an experience of being in a bloated FAANG team, this 150 includes GTA Online