Migrating to React Native's New Architecture

Summary

Shopify successfully migrated two largest apps, Shopify Mobile and Shopify Point of Sale, to React Native’s New Architecture while continuing weekly releases for millions of merchants. The strategy prioritized minimal code changes, dual-architecture compatibility, and performance and stability parity, with TopHat generating both architecture builds for every pull request. The team upgraded React Native first, updated or removed incompatible dependencies, and changed only native modules that failed under the new architecture rather than migrating all 40-plus modules to TurboModules. Migration issues included state batching, UIManager-related blank screens, shadow-tree manipulation, view flattening, and main-thread legacy module initialization; the reported outcome was maintained development velocity with no feature-development disruption, followed by planned optimization work.

Context

Shopify needed to migrate large production apps with hundreds of screens, native modules, custom components, and deep first-party library integrations while continuing weekly releases and serving millions of merchants. Pausing feature development was considered risky because it could delay essential features or bug fixes.

Approach / What changed

The migration used minimal initial code changes, dual-architecture compatibility during development, and performance and stability checks before release. Shopify generated old- and new-architecture builds for every pull request, used feature flags for incompatible dependencies and module implementations, upgraded React Native before app-specific work, and deferred broad TurboModule migration until after compatibility was established.

Takeaways

• TopHat generated builds for both architectures on every pull request, allowing continuous testing without local rebuilds and blocking new-architecture-breaking changes from merging.
• Shopify did not migrate all native modules to TurboModules; it changed only modules that failed under the New Architecture and planned to reassess more than 40 modules afterward.
• A Babel plugin set collapsable={false} on components with explicit test identifiers because view flattening caused reference and Appium discovery problems.

Related reading