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:

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

7. 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.

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.

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)

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:

1. 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.

2. Getting good performance on low-end Android phones was hard.

3. 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.

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.”

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:

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…

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:

What’s changed is that AI coding agents are now much more capable at generating iOS and Android code.

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:

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.

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 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 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.”

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.

Let’s return to the comparison table and update it for how native + AI changes the equation for Shopify:

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.

Most UI kits let you pass any style as a prop — radius, size, color, or a wall of Tailwind classes, whatever you need. That flexibility is exactly the problem: it turns every component call into a one-off styling decision, and no two buttons end up the same. Let’s talk about practices that prevent building an inconsistent, unmaintainable code base that won’t scale.

Look at this button built with Tailwind for example:

<button
  className="
    inline-flex items-center justify-center gap-2
    whitespace-nowrap rounded-md text-sm font-medium
    ring-offset-background transition-colors
    focus-visible:outline-none focus-visible:ring-2
    focus-visible:ring-ring focus-visible:ring-offset-2
    disabled:pointer-events-none disabled:opacity-50
    bg-primary text-primary-foreground
    hover:bg-primary/90
    h-10 px-4 py-2
    dark:bg-primary dark:text-primary-foreground
    dark:hover:bg-primary/90
    sm:h-9 sm:px-3
    md:h-10 md:px-4
    lg:text-base
    [&_svg]:pointer-events-none
    [&_svg]:size-4
    [&_svg]:shrink-0
  "
>
  Save changes
</button>

You can do the same thing with pure HTML too:

<button
  style="
    display: inline-flex;
    align-items: center;
    justify-content: center;
    gap: 0.5rem;
    white-space: nowrap;
    border-radius: 0.375rem;
    font-size: 0.875rem;
    line-height: 1.25rem;
    font-weight: 500;
    transition: color 150ms, background-color 150ms, border-color 150ms,
      text-decoration-color 150ms, fill 150ms, stroke 150ms;
    background-color: var(--primary);
    color: var(--primary-foreground);
    height: 2.5rem;
    padding: 0.5rem 1rem;
  "
>
  Save changes
</button>

Both examples do the same thing: the style is decided at the call site, instance by instance, instead of being named once and reused. That’s what I mean by inlining - the mechanism doesn’t matter, whether it’s a style attribute, style props, or a wall of utility classes.

Aside from the obvious technical issues of page size and caching, there are a few more important foundational problems:

1. you cannot ensure visual consistency, even within a single file
2. such code has no semantics, so you can’t tell what it means
3. such code has no system behind it, so it is difficult to maintain - even with an LLM you’ll wait a long time, because this error-prone style requires many iterations to correct

To address these problems, we need to stop deciding style at the call site and start defining it once, as a reusable, named unit of the interface.

The implementation depends on the stack, but most projects today build on component-based UI kits, so that’s what the examples below will use. Each component will be built from variants and modifiers.

Use variants

A variant is the self-contained style that completely describes all the visual aspects of a component, given a semantic name.

You can use a variant like this:

<Button variant="primary">Save changes</Button>
<Button variant="secondary">Cancel</Button>

In pure HTML with BEM methodology, it would look like this:

<button class="Button Button__variant_primary">Save changes</button>
<button class="Button Button__variant_secondary">Cancel</button>

A variant must contain all implementation details of the visual - inner geometry, colors, typography, everything. It must not expect its styles to be supplemented by anything external, whether that’s a global reset, a stray font-family, or any other in-place styling.

A variant defines the semantic unit of the user interface. That’s what makes a design system observable: you can see exactly which variants of a component exist and consistently update all of them at once.

Use modifiers

When you use a UI kit on a large project with a rich visual design, you may be tempted to write something like this:

<Button
	variant="primary"
	radius="xl"
	fontSize="xl"
	fontWeight={500}
	fontFamily="fancy"
>
	Buy
</Button>

This is the same call-site styling problem again, just typed: the props override the variant from outside, so it no longer defines the button’s final look. Worse, those overrides don’t track the variant — update the variant or introduce a new color scheme, and they silently fall out of sync.

If we need a variation of a view, we can implement a modifier instead, to keep things manageable. A modifier is part of the component’s API, at the same level as the variant - not an escape hatch around it.

For example, we can use variant to set the visual style of a button and add a modifier size to control its geometry:

<Button variant="primary" size="xl">Buy</Button>

If we find ourselves applying many modifiers at once, that’s a signal to introduce another variant instead:

<Button variant="fancy-primary" size="xl">Buy</Button>

This is the core discipline: variants and modifiers aren’t just two features of a UI kit, they’re a rule for where a styling decision is allowed to live, and when a recurring combination of modifiers has earned its own name.

The implementation example in vanilla CSS with a BEM-style modifier:

.button__size_xl {
	border-radius: 12px;
	font-size: 3rem;
	font-weight: 500;
	/* ... */
}

CSS modules for Mantine UI:

.root {
	&[data-size="xl"] {
		border-radius: 12px;
		font-size: 3rem;
		font-weight: 500;
		/* ... */
	}
}

ChakraUI theme:

export default defineConfig({
	theme: {
		semanticTokens: {
			colors: {
				// ...
			},
		},
		recipes: {
			button: defineRecipe({
				variants: {
					size: {
						xl: {
							borderRadius: "12px",
							fontSize: "3rem",
							fontWeight: "500",
						},
					},
					variant: {
						accent: {
							// ...
						},
					},
				},
			}),
		},
	},
});

Same rule, three different technologies - variants and modifiers work regardless of the tools you use.

Design the system

This approach can be applied to almost any UI kit, even one that wasn’t designed with this discipline in mind.

If you follow it, you’ll eventually end up with a design system even if you didn’t set out to build one - you’ll naturally be forced to identify the reusable units of your interface. Your code will stop being a pile of one-off styling decisions and start being a system.

Your project, your rules.

A community collection of ready-made contribution policies. Whether you welcome AI contributions, want everything written by humans, or something in between.

• AI Allowed

  Use any AI tooling you like. The usual contribution rules still apply.

  Permits

  • AI-generated code
  • AI-written text
  • Agent submissions
  • Private tooling

  Requires

  • Contribution guidelines

• Human Voice

  AI can help you, but it must never speak or think for you.

  Permits

  • AI-generated code
  • Private tooling

  Requires

  • Contribution guidelines
  • Human authorship
  • Full ownership

  Forbids

  • Unreviewed AI output

• Human Responsible

  Your tools are your business, but everything you submit must be yours.

  Requires

  • Contribution guidelines
  • Human authorship
  • Full ownership

  Forbids

  • AI disclosure notes
  • Unreviewed AI output
  • Unreproduced reports

• AI Disallowed

  No AI at all. Every contribution must be the contributor’s own work.

  Requires

  • Contribution guidelines
  • Human authorship

  Forbids

  • Any AI assistance

How to use a policy

1. Choose

   Compare the rules each policy sets and pick the one that fits.

2. Copy

   Copy or download the Markdown and save it as AI_POLICY.md in your repository.

3. Link

   Reference it from your CONTRIBUTING.md and pull request template.

Published

Tags

open sourcevaluescommunity