Why Shopify’s Mobile Team Stays with React Native

Shopify’s mobile engineering group has been all-in on React Native for years, shipping both the Shop app and the Point of Sale (POS) app on iOS and Android from a single TypeScript codebase. Over time, the team has formed clear opinions about where the framework shines and where it struggles. Three engineers—Stephen, Pablo, and Dennis—share their perspectives on what makes React Native productive for Shopify and where they push back on common criticisms.

The Real Advantage: Code Sharing, Not Just “Learn Once”

For Shopify, the primary value of React Native isn’t the developer experience or hot reload—it’s the ability to share logic across platforms and even with the web. The POS app, for example, shares code not only between iOS and Android but also with a web-based version of POS. That means business logic, state management, and validation rules are written once and used everywhere. When Shopify changes a tax rule or a discount policy, the fix propagates to every surface in a single release.

This is a different trade-off than the “learn once, write anywhere” promise. React Native doesn’t eliminate platform-specific work; it changes where that work happens. The engineers argue that the real win is architectural—forcing the team to separate platform-agnostic logic from platform-specific UI early, which keeps the shared core clean.

Looking Past the Old Complaints

Critics often point to React Native’s bridge architecture as a performance bottleneck. Shopify’s view is that the bridge-based design is largely a solved problem. The new architecture, including the Fabric renderer and the TurboModule system, removes most of the serialization overhead that plagued earlier versions. The team measures performance in terms of user-perceived speed, not raw throughput. For their use cases—forms, lists, and navigation—the framework meets the bar that users expect from native apps.

Another frequent complaint is the JavaScript ecosystem’s churn—new tools replacing old every few months. Shopify’s answer is to standardize internally on a minimal set of dependencies and to treat React Native’s own releases as the primary source of stability. The team is conservative about adopting new libraries and prefers boring, well-tested solutions over the latest hype. That discipline keeps the maintenance burden predictable across dozens of engineers contributing to the same codebase.

Success Metrics Beyond the Code

Shopify measures the success of React Native not by framework benchmarks but by shipping velocity and hiring efficiency. Mobile development has historically been a constrained pipeline: platform-specific skills are rarer than web skills, and a split iOS/Android team doubles the work for every feature.

With React Native, Shopify can train a mobile engineer in weeks, not months, and any developer who knows TypeScript can contribute to the mobile app. That removes a significant organizational bottleneck and allows feature teams to move at the speed of the web team. The result, they report, is that a dramatically smaller engineering team ships and maintains both large mobile apps than would be possible with fully native stacks.

The engineers also credit React Native with improving collaboration. Since the same engineers own both platforms simultaneously for a given feature, there is no more “iOS is done, now we wait for Android” handoff. Features ship together, which simplifies release logistics and makes it easier to reason about cross-platform behavior.

What the Engineers Would Change

Still, the engineers don’t present React Native as frictionless. They maintain a public list of bugs they’ve filed against the framework, and they are open about the pain points. Debugging is harder when the error spans JavaScript and native side, especially on the native side, where logs are less structured. They often interact with React Native internals where documentation is thin, forcing them to read the framework source to understand unexpected crashes on specific device types.

Their advice to other teams considering React Native is practical: don’t treat it as a shortcut to native performance. The framework is a layer, and you still need to understand what runs natively and how your interaction with that layer shapes performance. Teams that succeed are those that accept the native compilation step as part of their development loop and who treat the native components they write as first-class citizens of their app, not as hacks to be avoided.

What Keeps the Framework Alive

Shopify’s participation in the React Native community goes beyond being a user. Engineers on the team contribute pull requests, review RFCs, and maintain open communication with the core team at Meta. Their investment is strategic: they depend on the project’s long-term health and see their own engineering goals deeply tied to its evolution. In their view, the active open-source ecosystem—with companies like Coinbase, Discord, and Microsoft still using and improving the framework—is stronger evidence of its viability than any single vendor’s roadmap.

The engineers ultimately frame React Native not as a compromise but as a deliberate engineering choice. Starting with iOS in 2015, Shopify hit cost and portability walls with fully native development. React Native offered a path to maintain broad device support while keeping feature velocity high. As they see it, the alternatives each come with worse trade-offs—Kotlin Multiplatform would split their tooling, and a web-based app using a native wrapper would abandon the performance and UX quality they’ve achieved. React Native sits in a pragmatic middle that has worked for them for nearly a decade.

The Mixed Perspectives That Make React Native Work

React Native occupies an unusual position in mobile development: it promises web developers access to native platforms while offering native developers a faster path to cross-platform apps. At Shopify, three engineers from different backgrounds — web, Android, and iOS — came to React Native with different expectations and left with different opinions. Their experiences highlight both the strengths of the framework and the challenges that remain.

For AJ Robidas, a web developer, React Native was an immediate draw. She had been using React for years and was interested in mobile development, but had no desire to return to Java to build Android apps. The opportunity to write mobile apps in a familiar paradigm was the hook. Michelle Fernandez, an Android developer, was initially hesitant, worried that her native expertise would become obsolete. Ash Furrow, an iOS developer, was openly resistant when his team first adopted React Native in 2015 — he wanted to write Swift. It was only after learning React for web development that he understood the real value proposition: React Native lets you use React.

That tension between familiarity and novelty runs through all three experiences.

What Surprises New React Native Developers

Robidas was struck by the simplicity of React Native's building blocks — in a good way. The web has more than 100 semantic elements, from <button> to <footer>. React Native has just over 20 core components, and the structure is fundamentally different. There are no heading levels or paragraphs; all text is handled by the <Text> component. Interactive elements like buttons, links, and tabs are all handled through <Touchable> components. Writing a custom component feels almost identical to React, but the reduced semantic surface changes how you think about composing interfaces.

Fernandez was surprised by the speed of development. The instant feedback when updating the UI is incomparable to the delay of native builds, and pulling data with tools like GraphQL and Apollo is straightforward. She also found that creating native bridge modules to integrate existing SDKs was far less painful than expected. The outcome, she says, is a solid cross-platform app that still allows you to use the native layer when you need it — which is essential for Shopify's Point of Sale app.

Furrow's biggest surprise was quality. Earlier cross-platform frameworks like PhoneGap always felt like PhoneGap apps — they never belonged on the OS. Software written in React Native is hard to distinguish from software written in Swift or Objective-C. He had assumed the value of React Native was writing cross-platform apps with a single codebase, but at Artsy, where he used it for five years, it was only ever used on iOS. The declarative model, he argues, is simply a better way to create user interfaces — a consensus the industry has since reached as SwiftUI and Jetpack Compose play catch-up.

The Challenges of Switching to React Native

Robidas's biggest challenge was uncertainty. She came in confident in her React skills, but found herself unaware of mobile-specific concerns and when they might apply. CSS animations, for example, don't translate performantly over the React Native Bridge. Without a mobile background, those concerns were a blind spot — one filled by coworkers from native backgrounds.

For Fernandez, the challenge was the sheer volume of new tooling: the framework, the Metro server, Node, packages, hooks, state management. She found it helpful to draw analogies to native development. "You're not starting from scratch, you're starting from experience," she says. The syntax may be different, but the semantics are the same: figure out how to achieve the same result with a bit of JavaScript (TypeScript), and leverage native skills through the React bridge when needed.

Furrow was skeptical of the Node ecosystem, which felt like a house of cards. A fresh React Native project with over a thousand dependencies feels almost irresponsible to someone from a Swift and Objective-C background. He has come to appreciate it as a different approach to working around the unique constraints of JavaScript, but he doesn't blame anyone for feeling overwhelmed by the amount of tooling.

Pleasant Surprises

Robidas had expected simulator and emulator setup to be painful — her attempts to learn React Native on her own had stalled there. At Shopify, onboarding documentation and tutorials had her running a test app within minutes, letting her actually learn React Native instead of struggling with tooling.

Fernandez, coming from a powerful IDE like Android Studio, worried the development process would slow her down. Instead, she found that using IntelliJ IDEA let her write React code while also writing and inspecting native Kotlin code in the same environment. A good search-and-replace and refactoring system, she says, can speed up your dev process by 10x.

Furrow had dreaded writing JavaScript — nobody he knew really liked it, especially iOS developers. But he found that JavaScript had grown enormously, and TypeScript provided many of the compile-time advantages of Swift with a more humane approach to compilers. He can't imagine using React Native without TypeScript.

Where React Native Still Falls Short

All three developers identified areas where React Native needs improvement. Robidas pointed to accessibility. As an accessibility advocate, she pushes for accessible implementation in everything she works on, but React Native has little educational material on the subject. Many web principles apply, but the correct way to implement accessibility is not yet well established. With fewer semantic building blocks, very little is built in by default, so developers must be more aware and intentional.

Fernandez described React Native as "the wild wild west" compared to languages with well-established patterns, libraries, and documentation. Those resources exist for React Native, but the framework's relative youth and slow — though increasing — adoption mean there's still a long way to go in providing examples and references.

Furrow wished the tools were more cohesive. Having worked in the Apple developer ecosystem, he knows how empowering a polished developer tool can be. Apple's tools are far from perfect, he says, but they are cohesive — there's usually one way to accomplish a task. In React Native, he often finds himself figuring things out on his own.

When Opinions Changed

Robidas didn't experience a dramatic shift — she went in curious and uncertain, having heard good things from other web developers. The learning process went smoother than anticipated. Fernandez changed her mind when she realized that a React Native app could integrate with Shopify's native SDKs and still be performant. Kotlin over the React bridge works well, she found, and keeps her native development skills current.

Furrow's opinion changed when he built his first feature from the ground up in React for the web. The component model clicked. The next time he worked in Swift, everything felt cumbersome. He was spending time writing boilerplate that didn't make the software unique or valuable.

Working With React Native at Shopify

The three developers describe a supportive environment. Robidas credits a coworker's day-long introductory workshop, knowledgeable colleagues, and tooling built by the React Native Foundations team that removes most of the pain of getting started. Fernandez notes internal workshops, opportunities to learn from other teams using React Native, and dedicated mobile tooling teams supporting CI and production automation. Monthly mobile team meetups provide visibility into projects across the company. Furrow, still new to Shopify, highlights the investment in foundations: fast reload, downloadable bundles built for each pull request, and lint rules that catch common mistakes.

The common thread is that React Native teams at Shopify are deliberately staffed with developers from web, Android, and iOS backgrounds. Each perspective fills gaps in the others. Web developers bring familiarity with React's component model and best practices. Native developers bring deep knowledge of platform UI idioms, mobile constraints like battery life and network usage, and access to native APIs for geofencing, augmented reality, and push notifications — either through existing open source modules or custom native modules they can write. A purely React Native app can be good, Fernandez notes, but collaborating with native developers is what makes an app great.