Shopify’s Return to Native: What AI Changes for React Native

Shopify’s move back from React Native to native mobile development is a big change for an ecosystem it helped build. I have defended React Native for years and have recently worked on both React Native and native apps. I want to examine the company’s reasons, the benefits it may be giving up, and what agents change.

Shopify says its 2020 move to React Native succeeded: teams shared features, brought in developers without mobile backgrounds and reduced the work of keeping platforms in sync. It still considers the framework excellent. The new question is whether better coding agents have changed the cost of building separately in Swift and Kotlin.

I think the company’s explanation emphasizes cross-platform code sharing more than some other benefits I value. Shopify says it spent significant effort on performance, framework foundations and dependency upgrades, but those costs were previously worth the benefits. It revisited the decision after its assumptions changed.

Shopify experimented by rebuilding core parts of its apps using agents. It says agents could use one platform as a reference for the other and help developers contribute outside their primary stack. Separate native apps still require separate maintenance; the company believes the implementation and parity work is no longer as decisive as before.

The company also values closer access to platform capabilities and first-party tooling. I do not think this establishes that native is always better. Different teams have different dependencies, update needs and expertise, and Shopify’s internal setup is part of its particular decision.

The transition also affects libraries used by the community. Shopify says React Native Skia will move to a new home and name under its maintainer, with the old repository archived after the transition. It plans critical compatibility fixes for FlashList while discussing long-term stewardship, and intends to archive Restyle.

For large apps Shopify considered incremental migration versus a fresh rebuild. It chose a greenfield approach based on its prototypes and the advantages of a clean start. The company reports that Shop went from proof of concept to a rebuilt App Store release in twelve weeks; another larger Shopify app migration was underway.

Shopify says simply asking an LLM to recreate a feature in one shot produced unmaintainable code. Its Helix process instead proposes small checkpoints for each screen. Each checkpoint must match the running app through tests and visual review, pass two adversarial reviews and receive human approval before the next step.

I dislike parts of this approach and think teams can overvalue their existing implementation. That is my interpretation, not evidence of why Shopify chose it. Their process makes clear that agents do not remove the need to verify behavior and manage migration risk.

The company found simulator interaction slow and brittle, even with hot reloading. It describes separating business logic from the UI and providing a command-line interface so agents can inspect state and exercise behavior without always controlling a simulator. I think this is overengineered for their apps, but that is a judgment about a specific design.

Shopify thanks Meta, Software Mansion and its contributors for React Native’s development. The ecosystem’s investment is part of why the framework became useful in the first place. That matters when considering both the value of the platform and the implications of a large contributor changing direction.

I think the discussion underplays over-the-air updates. In a React Native app, an eligible JavaScript bundle can be updated without replacing the native binary. That can help teams deliver compatible fixes to users who do not immediately install app-store updates. It does not change native code and remains subject to platform policies and compatibility requirements.

Imagine a UI change that works on your test phones but is clipped on a smaller screen. A native fix may require another build, review and rollout, while users continue running older versions. At Twitch, I observed that many users were several releases behind; that was a particular app and period, not a universal update rate.

My analogy is a kitchen: native components do the cooking, while a JavaScript layer supplies instructions. Replacing compatible instructions can change behavior without swapping the underlying native code. The analogy simplifies the architecture, but it explains why I value the distribution flexibility.

I describe using updates for small fixes or switching an existing experience on and off. Store policies govern what is allowed, and not every change can be delivered over the air; native dependencies, binary compatibility and user update behavior still matter. Teams should check current platform rules rather than assume every feature can bypass review.

Expo provides build, update and development tooling around React Native. I compare it to a platform that makes the framework easier to use. Shopify’s degree of Expo adoption is discussed in the video as an inference from the article and conversation, not something I establish comprehensively.

My native iOS development setup requires signing and permissions for some features. I maintain separate configurations so I can test basic UI changes without reproducing every entitlement. With a suitable prebuilt React Native development client, teammates can iterate on JavaScript more easily, although changes to native code still need an appropriate build.

I also value Expo’s simulator and web support for some agent-driven iteration. A web build may help test shared logic and UI, but it is not a substitute for testing platform-specific behavior on the target device. I think Shopify may have missed some of these benefits, though its needs and integration costs could differ.

React Native has real drawbacks. Dependencies that contain native components can create difficult build and linking problems, especially across platform tooling. I am frustrated by packaging and the way upgrades can break, even when the JavaScript side looks straightforward.

People often cite application size. In the Shopify example I discuss, the rebuilt native app is not materially smaller; that single comparison cannot prove that size is irrelevant in all apps. Assets, localization, dependencies and the fact of a rewrite can all influence the result.

There are also programming pitfalls. Poorly handled effects or rendering can harm a mobile experience, and a framework’s accessibility to newcomers does not guarantee a good app. I make a broad claim about average developer skill in the video; it is my opinion, not a supported measurement.

React Native’s architectural changes and dependency upgrades can be disruptive, particularly when an app has substantial custom native integrations. I describe my own difficult upgrade experiences. Depending on Meta or a library to expose new platform features can also delay access, though teams can write native integrations themselves.

I do not treat general performance as an automatic loss for React Native. Background execution is one example with real platform constraints: JavaScript may not keep running when an iOS app sleeps, so some work needs native support and must still obey operating-system limits. The framework and native code can coexist.

Shopify says its native exploration coincided with React Native’s new architecture. The team had to weigh migrating existing native integrations to that architecture against a native rewrite. I think it would be useful to compare the old architecture, the new architecture and native implementations under matched conditions.

The new architecture improves how JavaScript and native components interact and offers other layout improvements. I expect it could change the performance comparison, but my video does not supply a controlled three-way benchmark. Shopify’s migration burden and app-specific requirements also matter.

I then discuss a public allegation about how Shopify CEO Tobi Lütke makes technical decisions. This is a disputed account, not something I establish from firsthand evidence. Lütke responds that the cited internal-tool situation involved an overly complicated architecture and that teams sometimes ask him to make a difficult call.

I agree that a small internal tool can be burdened by unnecessary layers. At Twitch, however, we also had reasons to share technologies between internal and public systems, including moving engineers and testing ideas. The right architecture depends on the team and the work rather than a single rule.

Lütke says he uses an internal podcast to explain decisions and teach the reasoning behind them. After reading his response, I am more sympathetic to the idea that a leader can help a team make a difficult decision. His response disputes details of the original allegation; neither account is independently verified here.

My own native experiment began when I had model access and spare tokens but limited time. T3 Code already had a React Native mobile app. I asked an agent to build a native version and was surprised when a working prototype appeared in roughly two hours.

Later I repeated the experiment with computer use and a different configuration. I mistakenly asked for AppKit, which is for macOS; one attempt inferred UIKit, while another produced SwiftUI. The result was two iOS prototypes alongside the React Native app, each produced in under three hours according to my account.

The native builds felt better to me in some navigation and background-data situations, but SwiftUI lists felt worse. Those are observations about early implementations of my app, not proof that either framework is inherently faster in all cases. The React Native version also had an excellent scrolling implementation.

The navigation story exposed an important usability detail. I swipe back from the left edge, while some teammates start closer to the middle. A stale drawer gesture in our React Native app intercepted a small area at the edge, so different people encountered different behavior. We found and removed that bug.

The SwiftUI version had a different issue: in my setup, the default navigation gesture did not cover the area a tester expected. I describe seeing broader swipe behavior in some built-in apps and ultimately rebuilding navigation to support the gestures our users tried. My experience does not establish every platform API’s behavior across versions.

AI made implementing the change easier, but it did not replace the work of noticing and understanding the interaction. It took me time to discover the different gestures and test them with another person. Platform-native components do not automatically guarantee that an app matches every user’s expectations.

I have found that an agent with source code, a simulator and an existing implementation can often produce a useful port and fix issues after feedback. I speculate about why Shopify’s experience differed, including model and tooling choices, but I do not know its internal causes. My app is also less complex than Shop.

I show an ongoing SwiftUI branch that an agent updated from changes in the React Native app. It reports porting several features and using a simulator. I use that build personally, but have not reviewed every line; one successful personal workflow does not establish maintainability or parity for all apps.

I also discuss Legend List, which our team uses for long lists in React Native and on the web. Its JavaScript implementation made a web version possible, and it performs well in our experience. A library author’s favorable benchmark claims should be evaluated against the actual app and workload.

React Native requires substantial work to expose platform functionality through a JavaScript-oriented interface. I praise the native engineers who built those integrations and argue that teams have benefited from their expertise. My estimates of historical team sizes are based on my understanding, not verified headcount data in the video.

I think coding agents can narrow some of the expertise gap that once pushed teams toward a shared framework. That does not eliminate the value of React Native’s development workflow, updates or well-tested libraries, and an agent-generated native app still needs maintenance and review.

I express concern that Meta’s investment and staffing around React and React Native have changed, citing departures and my understanding of the organization. The video does not establish the team’s full current staffing, plans or quality. My predictions about slower future maintenance are speculation, not confirmed outcomes.

I see Shopify’s move as an experiment worth watching, much as React Native was once a major bet on a different way to build mobile apps. A company’s decision reflects its own tools, people and priorities. It should prompt others to examine their assumptions, not automatically copy the choice.

For me React Native was never simply ‘write once, run everywhere.’ Knowing React can help a team learn and work across platforms, but understanding mobile behavior still matters. Whether the app is native or cross-platform, test it on both iOS and Android and pay attention to how real users navigate it.