Skip to content

SHOPIFY 2025-01-13 Tier 2

Read original ↗

Shopify — Five years of React Native at Shopify

Summary

Mustafa Ali (Director of Engineering at Shopify) publishes a five-year retrospective on Shopify's 2020 commitment to React Native (RN) as the future of mobile at Shopify, covering all mobile apps. The post is a rare public disclosure of a large-consumer-app mobile organisation's real experience with the native-vs-React- Native choice at scale: Shopify has now migrated all apps to RN over five years, on a per-team per-app schedule (not a big-bang rewrite), and the retrospective reports sub-500ms (P75) screen loads and >99.9% crash-free sessions across the portfolio. The architectural payload is the nine-lesson retrospective that crystallises a mixed-stack mobile architecture posture — RN for feature parity, native for device-hardware / memory- constrained / long-running-background capabilities — backed by a mixed-expertise team shape (native devs + web devs + RN specialists), a rotating framework-upgrade team, and shared foundations extracted after each app reached maturity.

The post is a Tier-2 on-scope architectural retrospective with real operational numbers and enough mechanism detail to canonicalise a mobile-engineering pattern family the wiki previously lacked entirely. It is the first Shopify ingest on the wiki.

Key takeaways

  1. Five-year migration completed on a per-team-per-app schedule, not a big bang. Shopify committed in 2020 to RN as the mobile future. Five years later, "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." Canonical datum for the team-autonomy-over- uniformity approach to a platform migration at consumer-app scale. (Source: sources/2025-01-13-shopify-five-years-of-react-native-at-shopify)

  2. **Operational result: sub-500ms (P75) screen loads and

    99.9% crash-free sessions. Verbatim: "Our apps are blazing fast (<500ms screen loads) and stable (>99.9% crash-free sessions)." These are the two load-bearing production numbers the post discloses. The perf number is qualified as P75 elsewhere in the post: "We've achieved sub-500ms (P75) screen loads in the Shopify app." Canonical first-party disclosure that RN is not automatically slow at consumer-app scale. Ali: "native doesn't automatically mean fast, and React Native doesn't automatically mean slow. RN has come a long way in the last few years and you can now use it to build world-class apps."

  3. "100% React Native should be an anti-goal" — mixed native + RN stack as architectural posture. Verbatim: "100% React Native should be an anti-goal. It is great for building features just once, but is not the right technology for everything." Native retained for: device-hardware features (2D/3D scanning, on-device AI models), memory-constrained features (home screen widgets, lock screen widgets, Apple Watch apps and complications, App Intents, Siri Shortcuts), and long-running background jobs (Point of Sale app: "downloads and syncs a ton of data in the background so that it can process transactions even when offline. By leveraging native code, we were able to offload that work completely to the background, ensuring that it had no effect on app performance."). Canonical closing formula: "Instead of thinking native or React Native, think native and React Native." Canonicalised as patterns/mixed-native-plus-cross-platform-mobile-stack.

  4. Framework upgrades are a dedicated-small-team problem, not an all-hands problem. Verbatim: "Updating an app to each new version of React Native takes a significant amount of work and often requires restructuring the code base. We have mitigated this by having a small group of rotating developers handle it while the rest of the team focuses on feature development." Canonicalised as patterns/rotating-framework-upgrade-team — the organisational response to framework-upgrade friction that preserves feature velocity. Expected to get easier with the New Architecture (reactnative.dev/architecture/ landing-page).

  5. Hot-reloading is the load-bearing devloop improvement over native. Verbatim: "The ability to see your changes reflect instantly with RN has been a total game changer. 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." Canonicalised as concepts/hot-reloading-devloop. Ali's canonical causal framing: minutes-of-compile-per- trivial-change breaks developer flow; instant reload restores it. The loss at native-code scale is measured in developer-hours-per-day, not milliseconds.

  6. TypeScript is the talent-portability unlock, not the language itself. Verbatim: "Typescript has become ubiquitous, and we've seen great success with developers transitioning between React web and React Native. Web developers find it much easier to start working on mobile using RN, as opposed to native iOS and Android development. Similarly, mobile developers familiar with RN find it easy to work on the web." Extends concepts/cross-platform-client-library into the talent-pool dimension — cross-platform reuse via a shared language lets a single engineer work across web + mobile. Creates staffing flexibility and code- sharing opportunities between web and mobile.

  7. Native devs remain essential. RN does not retire the iOS/Android specialist. Verbatim: "Mobile engineers who specialize in iOS and Android are essential to building great mobile apps. There is no replacing experience and taste that comes from having built many mobile products and deeply understanding conventions and usability. Being able to drop down to the platform layer, write bindings, master build & release, distribution, etc requires native expertise." Native devs also "play a vital role in optimizing app performance across the myriad of device models" and are essential for "managing React Native version updates, as well as adopting new features, APIs, and tooling changes that accompany new iOS and Android releases." Shopify's mitigation: self-serve course for training native devs on RN + office hours with proficient RN devs for Q&A / pair programming / code reviews + web devs seeded onto mobile teams for JS/TS/React expertise. The resulting team shape: native devs + web devs + RN specialists — the architectural fact of the mixed team as the enabler of the mixed stack.

  8. Debugging and 3rd-party libraries are the two still- real costs. Debugging: "Debugging in React Native is flakey and configuring it correctly in VSCode takes some work. iOS and Android on the other hand have powerful debugging capabilities that just work. Meta recently did a complete rewrite of React Native's debugger stack, which looks promising. We are collaborating with them to make it world-class." 3rd-party libraries: "The React Native framework is not as comprehensive compared to native, so you end up having to use more 3rd party libraries. The ecosystem has matured a lot in recent years and it is easy to find well-maintained libraries for anything you might need. This, however, adds the overhead of keeping them up to date on an ongoing basis and increases the surface area of supply chain attacks. We have mitigated this by implementing automated dependency updates using Dependabot and automated code scanning to catch malicious code. We'd love to see the framework get more opinionated and provide more capabilities out of the box." Supply-chain-surface- area-from-library-count disclosure is a real architectural trade-off.

  9. Shared foundations come after per-app maturity, not before. Verbatim: "When we first started adopting React Native, we did not have years of experience of building mobile apps using RN like we did with native. We also couldn't leverage the shared native foundations that we had built over the years, so each team built things their own way. It wasn't worth investing in creating those shared foundations at the time either because we were still learning how to build apps in RN. We were beginners again and had to first put in the time and effort to develop expertise. This approach was great to hit the ground running quickly and migrate our apps, but it also caused teams to solve the same problems multiple times, reinventing the wheel. This was a conscious tradeoff — we optimized for speed over consistency. By the end of 2023, all our apps were mature enough that we could start making them consistent. We have since started extracting common components like Identity, real-time monitoring, performance measurement, etc into shared libraries that all apps consume." Canonical timeline: 2020–2023 per- app autonomy / 2023→ shared-foundations extraction. Canonicalised as concepts/shared-mobile-foundations.

Operational numbers

  • <500ms (P75) screen loads in the Shopify app (post discloses Shopify app specifically; similar perf achieved in all apps).
  • >99.9% crash-free sessions across the app portfolio.
  • Five-year migration window (2020→2024-end) to get all apps to RN.
  • By end of 2023 all apps reached maturity and shared-foundations extraction began.

Shopify's open-source + ecosystem posture

Shopify contributes heavily to the RN ecosystem:

  • Code contributions to React Native proper.
  • Co-release captains for RN releases — a first- party-engineering-into-upstream arrangement.
  • Sponsors React Native Skia (GPU graphics) and Reanimated (animations).
  • Publishes FlashList (high-performance list component, addresses the FlatList perf pain Shopify saw), Restyle (React Native styling system), and Tophat (macOS app distribution).
  • Restarting the React Native Working Group in 2025 — previously included Meta, Twitter, Coinbase, Microsoft.

This ecosystem depth is the fourth invariant of Shopify's RN commitment: they aren't just a consumer of RN, they're one of the stewards.

Caveats

  • Unsigned-as-Shopify — Mustafa Ali byline. Director- of-Engineering voice, not a technical deep-dive. Zero architecture diagrams. Zero before/after migration numbers (e.g. no crash-rate delta, no perf delta vs native). The two production numbers (<500ms P75 / >99.9% crash-free) are post-migration only; no baseline.
  • "Screen load" undefined. P75 is disclosed; what counts as "load" (time-to-first-pixel? time-to- interactive? full hydration?) is not. Comparable to a web FCP / TTI gap in precision.
  • Native-vs-RN performance parity claim unsupported. Ali: "native doesn't automatically mean fast, and React Native doesn't automatically mean slow" — but doesn't disclose the measurement methodology to support parity, just a qualitative claim backed by three un-summarised linked deep-dives + YouTube talks.
  • Team-autonomy migration model cost not disclosed. "each team chose when and how to migrate" — total org- wide engineering cost, timeline variance, number of apps, team sizes all undisclosed. Per-team-per-app schedule preserved optionality at the cost of a long total timeline (five years).
  • Shared-foundations extraction cost not disclosed. By end of 2023 "all our apps were mature enough" to begin extraction — but the cost of extraction itself (team size, timeline, compatibility work, version-skew mitigation) is not walked.
  • Debugger state is a real cost. "Debugging in React Native is flakey" is candid; collaboration with Meta on the rewrite is mentioned but not quantified.
  • 3rd-party library count + upgrade-cadence not disclosed. Dependabot usage + code-scanning mentioned as mitigation but no supply-chain-incident disclosure.
  • No mention of Shopify's POS hardware-integration specifics (card readers, printer drivers) despite POS being named as the canonical background-jobs-via- native example.
  • New Architecture migration status ambiguous. Ali names it + commits "We are... committed to adopting it in our apps" — but whether any Shopify apps were on the New Architecture at publication time is unclear. (A separate 2025-09-12 Shopify post exists on the wiki's raw corpus specifically covering the New Architecture migration.)
  • Retrospective voice. Not a post-mortem, not an incident narrative. Director-of-Engineering altitude. Load-bearing as first-party validation that a large consumer-app org that made the RN bet would make it again.

Cross-source continuity

First Shopify ingest on the wiki. Opens the Shopify corpus — subsequent Shopify ingests (e.g. the 2025-09-12 Migrating to React Native's New Architecture post) will compose against this retrospective as the baseline.

Sibling to Meta's sources/2026-01-28-meta-rust-at-scale-an-added-layer-of-security-for-whatsapp|2026-01-28 WhatsApp Rust-at-scale post at the cross-platform-client-library axis — both canonicalise "single shared implementation, multiple end-user platforms" as the architectural pattern, but at different altitudes: WhatsApp's wamedia is a single library shipped as a cross-platform artefact; Shopify's RN is a cross- platform application framework running entire app surfaces. The two bracket the cross-platform space: Meta's framing is "write the security-critical library once; compile to every platform"; Shopify's framing is "write the feature-parity-critical features once; bridge to native where it's the right tool." Both treat native expertise as load-bearing.

Source

Last updated · 470 distilled / 1,213 read