Why has Shopify dropped React Native?

extract

Before we start: given this article is about native mobile development, I want to offer my 2021 ebook, ‘Building Mobile Apps at Scale: 39 engineering challenges’, for free to all readers. (normally costs $20). The book remains relevant on the challenges to solve for large-scale mobile applications, and lists the technologies covered below in this article, Kotlin Multiplatform included. Claim your free copy here This offer is valid until Friday, 2 October. On checkout, simply select “The ebook: PDF & EPUB versions of the book.” No credit card required! Feel free to share the link with colleagues who build mobile apps, or work on them. Recently, Shopify dropped the bombshell announcement that Native is now the future of mobile development at the e-commerce platform. This triggered a lot of reaction in the mobile development community, on the scale of the stir Shopify generated when it originally moved over to React Native six years ago. But times have changed, and we all know the agent of change this time: AI agents! This latest generation of models has improved in coding capability to the extent that Shopify no longer is satisfied with React Native (RN), as it was only last year. This article looks into what led here, why Shopify made the change, and also the broader mobile ecosystem. We cover: Why Shopify chose React Native in 2020. Android apps took too long to build, first and foremost, and it was nice to have consistent iOS and Android apps. Still happy five years later. Shopify moved all six apps over to RN and most things were going well, and the 2020 move was seen as a good move. Why ditch React Native now? AI is now very good at writing mobile code as well as backend code, while React Native adds abstractions that native does not. Shopify rewrote the Shop app to native in just 12 weeks(!!). Additional details from the Shopify mobile team. Haven’t we seen this back-and-forth before? Airbnb did something similar by adopting React Native in 2016 before moving back to native just two years later. The underlying reason was the same: performance. Going native since 2019. Moving to native used to take a long time, and Notion has been at it for seven years. When Notion finishes the process, a fair question will be whether a native editor actually slows down their web iteration speed, with or without AI. Kotlin Multiplatform (KMP) would like a word. KMP allows the writing of business logic in Kotlin and sharing it across iOS and Android while each platform stays native. It’s a technology that feels relevant, and could become more popular with AI. What’s next? It’s easier to write native iOS and Android apps than before, but that’s also true for React, Flutter, and KMP apps. 1. Why Shopify chose React Native in 2020 Let’s rewind to 2020, when Shopify decided to go all-in on React Native (RN). Back then, mobile was a very important channel for the platform, with seven out of 10 customers using it on mobile devices. As Head of Engineering, Farhan Thawar wrote at the time: “Each quarter, the majority of buyers purchase on mobile (with 71% of our buyers purchasing on mobile in Q3 of last year [in 2019]). Black Friday and Cyber Monday (together, BFCM) are the busiest time of year for our merchants, and buying activity during those days is a bellwether. During this year’s BFCM, Shopify merchants saw another 3% increase in purchases on mobile, an average of 69% of sales.” With mobile so important, it’s no surprise the company built native mobile applications for iOS and Android; after all, native mobile gives full control of a platform’s capabilities, integrations, and performance, so why bother with cross-platform technology? It turns out one reason was the delay in launching native apps on Android, which Shopify struggled with, along with other companies. When Android takes a year+ to launch: the Clubhouse fail During the pandemic at the start of the decade, the live conversations app Clubhouse was a massive hit after launching in March 2020. The app was iOS-only for the first 14 months as the team was unable to release an Android app. And at the end of the year, usage absolutely exploded: December 2020: 600,000 global installs (downloads) (source) January 2021: 3.5 million global installs (source) February 2022: 8 million global installs (source) Clubhouse app: voice chat blew up with Covid-19. Source: TechCrunch Despite all that popularity, Clubhouse was unavailable on Android at the time! It took 14 months to launch a beta version of Clubhouse on Android, and by the time it did in May 2021, the platform had passed its peak a few months earlier and usage numbers were by then trending down. It took until July 2021 to roll out the Android Clubhouse app globally – 16 months after the iOS version – by which time it was too late to catch the growth wave, and that spelt doom for the promising business. How did this happen? There were a few main reasons: Android is more complex to build well for than iOS: more device types to support, and much older OS versions to support with different APIs. Getting good performance on low-end Android phones was hard. I also wonder if Clubhouse’s team was engineering for a scale that never materialized. Perhaps they tried to build the “perfect” app to launch globally, but missed the growth wave, meaning the app ended up “over-engineered” compared to a different version that could’ve been released sooner, in a more timely fashion that benefitted the business. Building a native Android app from scratch – even with an existing iOS app as a blueprint – was a challenge during the 2010s and early 2020s. Clubhouse is an extreme case of a business which went wrong, partly due to a sluggish Android launch. But customer habits could have played a part: at the time, most US startups prioritized iOS apps and features first because in the US, the most valuable users were increasingly found on iOS. Prioritizing iOS made business sense for companies with mainly US customers, but not for ones with a global footprint, where regions like Asia featured mainly Android smartphone users. React Native helped Shopify add Android support faster Shopify’s first positive experience with React Native was in 2018 with the Shop app (then called ‘Arrive’). The company summarized (emphasis mine): “At the end of 2018, we decided to rewrite one of our most popular consumer apps, Arrive (which is now Shop app) in React Native. Arrive is no slouch; it’s a highly rated, high performing app that has millions of downloads on iOS. It was a good candidate because we didn’t have an Android version. Our efforts would help us reach all of the Android users who were clamoring for Arrive. It’s now React Native on both iOS and Android and shares 95% of the same code. We’ll do a deep dive into Arrive in a future blog post. So far, this rewrite resulted in: fewer crashes on iOS than our native iOS app an Android version launched a team composed of mobile + non-mobile developers.” Moving over to React Native was one of the easiest ways to speed up the rollout of Android versions of new apps. In 2020, when Shopify announced the move, that was the stated intention: “Our popular Shopify Ping app (now called Shopify Inbox) which has enabled hundreds of thousands of customer conversations is currently only iOS. In 2020, we’ll be building the Android version using React Native out of our San Francisco office and we’re hiring.” 2. Still happy five years later Last year, Shopify declared it was satisfied with the move to RN in a recap article, ‘Five years of React Native’. The summary was quite the victory lap: “To recap, we decided to switch to RN for three main reasons: Write it once - Stop building the same features twice, once on iOS and once on Android Talent portability - Enable devs to work fluently across iOS, Android, and Web Ship more value - Spend more time delivering value to users instead of chasing feature parity We’re happy to share that our transition has been quite successful: Not having to build the same features twice has given us a step change in productivity Engineers are able to work across web and mobile allowing teams to do more with the same number of people and unlocked new growth opportunities Maintaining feature parity between iOS and Android has become a non-issue, freeing up capacity to ship a lot more value Our apps are blazing fast (<500ms screen loads) and stable (>99.9% crash-free sessions) We continue to leverage native wherever it is the best tool for the job, giving us the best of both worlds Over the past 5 years, we have migrated all our apps to React Native. Instead of using a one-size-fits-all approach to do so, each team chose when and how to migrate their app. This allowed them to continue shipping features while also aligning with our strategy of leveraging RN.” They weren’t kidding: in five years, six mobile apps were migrated to React Native: App migrations to React Native Shopify’s engineering team said they loved a lot about React Native. Mustafa explained: “Speed. RN apps are fast. We’ve achieved sub-500ms (P75) screen loads in the Shopify app. We’ve achieved similar performance in all our apps. Just like native, you have to apply good patterns and techniques to eliminate performance bottlenecks. Hot reloading. This was one of our biggest pain points with native. Given the size of our code bases, it took several minutes for even the most trivial changes to be compiled and run on an emulator/physical device. This wastes time and breaks developer flow. React Native’s hot reloading completely eliminates this problem. TypeScript is awesome as the “shared” language for devs. TypeScript has become ubiquitous, and we’ve seen great success with developers transitioning between React web and React Native.” There were also some new challenges: Worse debugging: “Debugging in React Native is flaky and configuring it correctly in VS Code takes some work. iOS and Android on the other hand have powerful debugging capabilities that just work” Native code and devs still important. You want native code for performance-intensive code, certain animations, long-running background jobs and specialist APIs (like home screen widgets). More third-party libraries. “The React Native framework is not as comprehensive compared to Native, so you end up having to use more third-party libraries.” But how quickly things can change in tech… 3. Why ditch React Native now? There was widespread surprise this month when Shopify announced that Native is now the future of mobile at Shopify, meaning that RN is suddenly history. From Head of Mobile, Mustafa Ali (emphasis mine): “In January 2025, I wrote that the future of React Native was bright and that Shopify planned to keep investing in it. That was true based on what we knew then. React Native was working well for us, and it remains an excellent framework. But since then, coding models have gotten dramatically better, and for our apps and our team, building the same feature in Swift and Kotlin no longer carries the cost it used to. Native still means building and maintaining software on two platforms, that cost has not disappeared. What 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. React Native apps can be fast. Ours are. We are making this change because agents have reduced the advantages of sharing implementation, while the advantages of building for each platform remain. Native keeps us closer to platform capabilities and first-party tooling, with fewer framework and dependency layers between our code and the platform.” Of course, there have always been pros and cons in choosing native over cross-platform. Pre-AI, this is how it looked: Native vs React Native development, observed across these four dimensions What’s changed is that AI coding agents are now much more capable at generating iOS and Android code. How React Native renders elements – a recap There’s no doubt that fully native apps are well-built and always more efficient than those built on a cross-platform interpreter like React Native. Nonetheless, RN has come a long way to be much more performant – with one additional abstraction layer between RN code and native code – especially since the New Architecture of 2024, Let’s visualize how it works: How React Native renders views on iOS and Android React Native’s core philosophy is to minimize updates done on the UI using expensive rendering operations. So, RN maintains a React Host Tree of visual elements on a screen (think a “logical tree”) which transform into a Host View Tree, the representation on iOS and Android. React itself cleverly minimizes re-rendering operations, which saves on compute resources. Why performance necessarily wins with native apps As mentioned above, a well-written native app naturally outperforms a React Native version. The easiest way to see why this is, is to sketch what happens with native apps rendering, compared to with React Native: React Native vs native rendering React Native can theoretically be more performant, in the unlikely event the Native version has a poorly written structure, or if UIKit / Jetpack Compose or any other native library is inefficient enough for this to happen! But native has many fewer abstraction layers. One common question since Shopify moved to native is how come the Shop app had not moved over to the New Architecture to improve things like startup performance. I reached out to Head of Mobile, Mustafa Ali, about that. He told me: “We actually moved other big Shopify apps to the New Architecture. Shopify and Point of Sale were both migrated, and I believe we were one of the first large teams outside Meta to do it. We got some performance gains with this migration, but they were modest. App startup got about 10% faster on Android and 3% on iOS, and some complex screens actually got slower until we tuned them.” The team has written in detail about the move to New Architecture. Nonetheless, being on native code provides a lot more opportunities to improve performance; after all, you can now control the complete rendering stack! Heck, you could also throw away the Apple-built system libraries like UIKit or ComposeKit and build more performant ones. Shopify doesn’t plan to go this far, but Head of Engineering, Farhan Thawar, told me they expect performance wins: “I think we’re just at the beginning of how much better these native apps will be. I expect they will get faster – like with better startup time and more responsive interactivity – as we work through the codebase post migration.” One engineer, two platforms with AI One benefit of React Native was that it wasn’t necessary to have both an iOS engineer and an Android engineer. But with AI, one engineer can build software on both platforms, Mustafa Ali told me: “One cultural benefit of switching to RN in the past is that we don’t have a separate iOS and Android team, unlike most native shops. We have one team, and the same developer builds a feature on both iOS and Android. This keeps the context in one place and there’s no communication overhead. With LLMs making it easy to contribute code outside of your main expertise, I expect this to become more common in the coming months.” Farhan put it even more simply: “Basically, React, as the shared language, is now replaced by the English language, thanks to LLMs.” Shared codebases more trivial with AI Another downside of going native is having two codebases to maintain, which tend to diverge from each other in behavior, features, and bugs. But with AI, Shopify doesn’t see this as a big problem any more. Mustafa: “Maintaining two separate codebases was a big deal before LLMs, but not anymore. Agents are quite good at porting a feature from Android to iOS or the other way around. They are also good at comparing the two implementations over time. They can spot gaps in the code and in side-by-side testing, and fix them.” Shopify is also building a shared verification test suite to validate the two apps as identical. Again, from Mustafa: “We now have one shared test suite that validates business logic implemented in both Swift and Kotlin. This means that a feature can’t ship until it passes the exact same tests on both platforms. That logic runs headless on desktop, which gives agents a very fast feedback loop to iterate on.” Smart! It also confirms my sense that verifying code is becoming very important for working with agents, as is building dedicated verification layers. How React Native & native compare today Let’s return to the comparison table and update it for how native + AI changes the equation for Shopify: Native vs React Native development, with more capable AI agents My personal sense is that the downsides of native development disappear with AI tools getting so good, and that Shopify now has full control over the performance and architecture of its native apps. With the decision to go all-in on native with AI, the e-commerce business is committing to migrate all of its apps. With AI, it should be faster than the migration to React Native was. Mustafa, again: “We are going to migrate all our mobile apps to Swift and Kotlin using AI throughout the process. Shop has already shipped as a fully native app in just 12 weeks, the Shopify app is underway, and the rest will follow soon. We’re moving quickly, but not by lowering the bar. Every rebuild must meet or exceed the performance, stability, accessibility, and product quality people expect today. This isn’t just the same apps rewritten in different languages. We’re rebuilding them so both humans and agents can understand, test, and change them quickly.” Best of luck to the team with this migration! I’m looking forward to hearing about what they learn with this move. 4. Haven’t we seen this back-and-forth before? Read more