# Senior Developers Criticize Shopify for Ditching React Native https://belitsoft.com/shopify-react-native ## Shopify is ditching React Native in favor of Swift and Kotlin Back in 2020, Shopify announced that they were fully committed to building any new mobile applications with React Native. In their words, this was the future. In January of 2025, Mustafa Ali, who works at Shopify, [wrote an article](https://shopify.engineering/five-years-of-react-native-at-shopify) summarizing and reflecting on five years of using React Native at Shopify. He wrote that the future of React Native was bright and that Shopify planned to keep investing in it. React Native was working well for them and, according to the article, remained an excellent framework. But native is now the future of mobile at Shopify. In September 2026, Shopify [announced their plans](https://shopify.engineering/back-to-native) to move off React Native and go back to native code. According to Shopify, coding agents change what it costs to build mobile apps twice, and that's why they're moving from React Native back to Swift and Kotlin. Coding models have gotten dramatically better, and for their apps and their team, building the same feature in Swift and Kotlin no longer carries the cost it used to. Shopify has been using LLMs to build software since 2021, a year before ChatGPT even launched. Initially, they used them to implement features, investigate and fix bugs, and review code. By late 2025, the models were capable enough that they questioned whether building software twice still meant doing twice the work. They rebuilt several core parts of their biggest apps in Swift and Kotlin using LLMs, and they were surprised at how well it worked. Agents could implement features on Android using the iOS version as a reference, and vice versa. They reduced the cost of maintaining parity between platforms through shared specs, tests, and review checkpoints. To develop everything natively in Kotlin and Swift, you have to build and maintain the same product twice, and that cost has not disappeared. What's changed is that agents can now do enough of the implementation, translation, testing, and review work that it's no longer the deciding factor it was in 2020. They're making the change because agents have reduced the advantages of sharing an implementation, while the advantages of building for each platform remain. Native keeps them closer to platform capabilities and tooling, with fewer frameworks and dependency layers between their code and the platform. ### What has already migrated The Shop app, which is regularly at the top of the shopping category in the App Store, was the first to migrate. Assisted by AI, the Shopify team went from a proof of concept to a fully rebuilt app published in the App Store in just 12 weeks. They've [written about that migration](https://shopify.engineering/shop-app-migration) in depth. The Shopify app is next. It has 300+ screens, Home Screen and Lock Screen widgets, an Apple Watch app with complications, Siri Shortcuts, and more. That migration is underway and ships later this year. ### What happens to the libraries Shopify maintained #### React Native Skia Skia is a graphics engine that powers Android and Chrome, though it's largely associated with Flutter (funny, given Flutter is moving off it). It lets you do fancy animations and crazy buttons that you'd normally do in a game engine, without being limited to native elements and layers. Shopify built React Native Skia so you get those benefits for the specific screens that need them, like Instagram Stories, where you layer things on top of a photo. Skia is way better for that than plain React Native or even native. William Candillon, a Shopify contractor and one of the best React Native YouTubers, keeps working on it. He'll fork it in the coming months and start publishing the library under a new name. The original repo will be archived when the transition is complete, with updates along the way so everyone has ample time to migrate. If you use it, consider sponsoring it. #### FlashList It has become the default list component for most React Native projects. Given how important this library is, Shopify will continue to fix critical issues that break compatibility, and it's in discussion with several companies about taking on long-term stewardship. ## Senior developers criticize Shopify for ditching React Native ### "Native is easier now due to AI" is an opinion, not a fact Saying that you can now delegate two separate codebases to AI doesn't mean that cross-platform frameworks are suddenly useless. **AI has not solved the underlying problem:** - Even with AI, you will have to deploy and maintain two different repos, so double the codebases, code reviews, languages, and required expertise. Now you have twice the number of Jira tickets to push around. - It's still quicker to write and maintain one app than two. Small teams or solo developers can still review the code and ship faster if it's one codebase with AI. - With the web, it's not two codebases but three. Three different platforms are still three different codebases. **The rewrite doesn't remove the maintenance burden** In the long run, it looks like Shopify is moving from "performance tech debt" that it owns to future tech debt that… no one owns. Splitting into two codebases will eventually increase the maintenance burden and technical debt no matter how good your harness is. **Creating a larger surface area for bugs** AI is surprisingly good at creating small inconsistencies as codebases grow. An LLM might even create a feature in both repos without bugs 80% of the time. If you don't want bugs, or even security holes, the other 20% of the time, you cannot trust AI-generated code without review. You have to review the code, and your devs need to know Kotlin and Swift to do so, not just React Native. **Is LLM-generated code actually cheap?** If you look at what agent subscriptions cost across a company, it definitely is not. To get the kind of output you want, you would have to pay an insane amount of money. It's a lot of tokens to run agent loops. "A big company replaces a $100k developer with $100k on AI agents for worse quality?" — @Stone\_624, *YouTube* The current core assumption may be that token prices will stay this cheap or get cheaper. "Five years later, when the highly subsidised $200 plan goes away, Shopify: It's too expensive! We have to use React Native!" — @abcabc-ur3bf, *YouTube* **Why not use agents to ship faster on React Native instead of going native with them?** Couldn't we argue that AI should be helping make React Native even more performant and get all the performance you could get from fully native apps? React Native allows for native modules, so if Shopify had issues, it could've used AI to fix those instead of a rewrite with the potential for bugs. ### Expo for React Native is so good that with it you don't have to go native. But Shopify never fully adopted it Expo is a React Native framework that makes developing Android and iOS apps [easier](https://docs.expo.dev/get-started/create-a-project/). Since 2024, using a framework such as Expo has been the [recommended](https://reactnative.dev/blog/2024/06/25/use-a-framework-to-build-react-native-apps) approach to creating new apps. Using React Native without a framework is also supported. Expo is kind of the Next.js/Vercel of the React Native world. The Expo team has built much of the tooling needed to make React Native a good experience to work with. You can use their servers for builds, share those builds with your team, and push out over-the-air (OTA) updates. Theo Browne, a developer and YouTuber (t3.gg), argues that Shopify never fully adopted Expo, so it wasn't getting many of those benefits. **The Expo team makes it easy to get a good dev client** A dev client is a debug build of your app that loads its JavaScript from your computer. Theo thinks this is one of the biggest benefits of React Native. You don't need another native build until you change the native code. **You can share a dev version of the app** With React Native and Expo, you only need one dev to go through the signing process, and they can make a dev version of the app. Once you have that installed, you scan a QR code, you change the JavaScript code, and now you're working on the app. Can you make changes to the native share screen code without another build? No. But if you want to test how your new feature works with the share feature already in the app, you can change the JavaScript and do that. Shopify says agents can make code changes in seconds, but it takes them several minutes to test the output, which is especially difficult on mobile. To get around that, Shopify built its own CLI that lets agents iterate on the business logic in milliseconds instead of minutes, without involving simulators. But you don't have to go native to give agents a fast feedback loop. Agents work with React Native and Expo too. Expo has really good simulator support as well as web support, so agents can do a lot of the iteration without a native build. Testing your logic in the whole app compiled for web is even slightly better than testing it through a custom CLI. If you're using React Native without Expo, you're probably rebuilding Expo, because you need all of this tooling anyway. ### Shopify glossed over React Native OTA updates #### Native developers deliver fixes through app store updates, which users may not install right away Apple and Google don't want you to do updates outside their official stores. If you have a feature in native code (let's say a new button in a menu), and you ship it to all your users, you have a problem if this feature becomes a bug on some devices, like the iPhone mini (where the button gets cut off on the smaller screen you didn't account for). This can happen even if you test it on your phones and it all looks good, including in TestFlight. When you get a message about the bug from a customer, you have to decide: fix it or leave it out there as is. If you leave it, you'll be supporting all these angry requests from customers without solving their problem. If you decide to fix it, you have to make a whole new version of the app and put it up in the App Store or Google Play, so that everyone who downloads it has the fixed version. "You must create and submit a new version." — [Apple](https://developer.apple.com/help/app-store-connect/update-your-app/create-a-new-version) "An app distributed via Google Play may not modify, replace, or update itself using any method other than Google Play's update mechanism." — [Google Play](https://support.google.com/googleplay/android-developer/answer/16559646?hl=en) But you can't guarantee that the new version will be installed immediately for everyone. Some users will get it through automatic updates; others may have to install it themselves. So you still have to support the angry requests from customers, only now the answer is "install the update." Both stores make an exception for interpreted code such as JavaScript, as long as an update doesn't change what the app is for. That exception is what makes OTA updates possible. **Your users have different versions of the same app at any given time** Just because Apple has approved the update doesn't mean all your users have it on their devices. What this means is you don't really have one app on iOS and Android. You have every version anyone still has installed, unless you've built in a way to deprecate old ones. And that makes it so much harder to build apps. You have to worry about forward and backward compatibility. And so do your servers and so does your support team. If you accidentally ship a bug and fix it an hour later, you can still get reports about that bug for months, if not years, because it takes so long for people to get updates on their devices. And sometimes you open an app and a big warning pops up saying, "Hey, you need to go to the app store and install the latest version." So you've fixed the bug, but the user still has to go to the app store and update the app to get the fix. #### React Native developers can deliver fixes through OTA updates, which the app downloads automatically If the JavaScript layer tells the native layer where to put that button, you can fix its layout and push up an OTA without making a new native build. The app can automatically download the updated JavaScript bundle, which tells the native layer how to behave differently. "EAS Update makes fixing small bugs and pushing quick fixes a snap in between app store submissions." — [Expo](https://docs.expo.dev/eas-update/introduction/) Maybe this isn't a problem for Shopify, and it can live without OTA updates. But for smaller products with a small dev team, maybe two or three people, this is a major downside of going native. **OTA updating makes it easier to understand what React Native actually is** React Native is a command layer to control what native elements are rendered. It's not a replacement for native. It uses the JavaScript layer to tell the native layer on your phone where to put things and what to do. React Native uses the native components that make the app function. OTA lets you change the app's JavaScript and assets without changing the native code, and ship compatible fixes and temporary changes without submitting a new app build. Let's say you have a bug or an issue or a thing you want to turn on and off, like a fancy background on a specific holiday on your homepage that you want to have in the app for a day and then out the next. In order to do that natively, if you haven't already built in a way to control it remotely, you have to plan ahead to include it, hope your users are on the latest version by the time that date hits, and have it set to turn on at the start of the day and off at the end. And if something goes wrong that needs a change to the native code, you're back to shipping another app update. With React Native, you can push up the OTA for it at the start of the day and push up another one to get rid of it at the end. If something goes wrong in the JavaScript code, you can push up a new OTA with the fix. Since the JavaScript bundle is redownloaded automatically and tells the native layer how to behave differently, you can get small fixes out without submitting a new app build. "There are three letters that make it really hard to not use React Native if you can justify it. Those letters are OTA: over-the-air updates. I will miss OTAs if I go native." — Theo ### The Shop app used the old React Native architecture At the end of 2024, React Native overhauled its core [architecture](https://reactnative.dev/blog/2024/10/23/the-new-architecture-is-here). The bridge, through which the JavaScript layer tells the native layer what to do, was removed, and that made React Native apps way faster. The New Architecture addresses a lot of the performance issues. It makes it easier to get things in and out of the native layer. There are also improvements to core functionality like synchronizing layouts and effects. You can read layout information synchronously in `useLayoutEffect` and update the UI in the same frame, instead of waiting for an asynchronous `onLayout` event and having things jump around after they've already appeared on screen. There are a lot of these little things that improve how much performance you can squeeze out of React Native. And it's already running in production at Meta, including in the Facebook app. Shopify was on the old architecture. "…our next major React Native investment: adopting the New Architecture." — [Shopify](https://shopify.engineering/shop-app-migration) Shopify was planning to move to the New Architecture but in the end abandoned the migration in favor of two native codebases. The company decided to ditch React Native without ever trying the New Architecture. Shopify says it would have had to go back through how its native modules were hooked up, how the app rendered things, and which parts of the code were shared versus written separately for iOS and Android. With the amount of native stuff it had written, the port would not have been trivial. But agents could have helped with that work too. "It would have been nice to see React Native's old architecture versus the New Architecture versus native. I bet the gap would be smaller, but that's a comparison we don't have." — Theo ### Don't compare Shopify to the rest of the market Here is how, by Theo's account, decisions like this are made at Shopify: "If you've ever worked at Shopify, you know decisions like this are made directly by Tobi, the founder and CEO of Shopify, abruptly over a weekend and they are forced on the entire company without any input from the people actually working on the apps. For a few weeks, Tobi was convinced React is slow and there was a companywide decision to move from React to Ruby on Rails for all new projects and to migrate some existing things to Ruby on Rails. Then two weeks later, he learned about server components and then removed all of the internal articles bashing React and canceled the migration decision. It happens so commonly that he drops in some Slack channel and demands things to be immediately changed without allowing any conversation with the team members. This is a thing he has historically been known for, allegedly." — Theo, *Did AI Kill React Native* Shopify gives a signal about where the industry is going, but that doesn't mean you should rewrite your app over a weekend, even though it might sound fun. If you can't afford a team to actually maintain two products, you shouldn't do it. Just because a giant shifts its tech paradigm doesn't mean a startup with an AI subscription can replicate that. Shopify can afford to burn money on AI agents, and it has a mobile team large enough to staff two native codebases. Smaller companies don't have that luxury: they still rely on React Native or Flutter because they're way more cost-effective. Remember, Shopify used the React Native codebase for the migration. It wasn't an exclusively vibe-coded migration. If you are two people shipping an app, a model writing your Swift code doesn't help you when there's nobody to review it, and maintaining two platforms is still maintaining two platforms. Even "the same" app is two different apps, because not all UX translates the same way to both platforms. If you have a simple app or a small company, it's still way easier to just develop one Expo app.