Shopify Returns to Native: Lessons from a Changing Cost Structure

In September 2026, Shopify Engineering published an article outlining its future direction for mobile development. The title is as follows.

Native is now the future of mobile at Shopify

In 2020, the company announced a policy of shifting mobile development toward React Native. It also continued to invest in the external developer community. That same company has now announced a return to in-house development with Swift and Kotlin. The impact on the industry is significant.

Reporting by Nkzn on Zenn cautioned against interpreting this move as a “failure of React Native.” Shopify itself does not disavow its past choice. The framing is that a change in cost structure drove the decision. This article examines that argument in depth.

Shopify Engineering’s official blog explains the evolution of its development organization and its current judgment. It is not simply about the merits of one framework over another. The issue is where implementation and maintenance costs lie.

Shopify’s Shift in Development Policy

In 2020, Shopify was implementing the same features twice for iOS and Android. Synchronizing specifications also took time. There was also the challenge that engineers whose main field was the web found it difficult to participate.

Adopting React Native was a means of reducing this duplication. A single implementation could cover both platforms. Knowledge of web technologies could be reused. Faster development was expected.

The 2026 article showed that this premise had changed. Automatic code generation and review infrastructure had been put in place. The burden of maintaining two tracks of native development had relatively decreased. Meanwhile, the burden associated with using a framework remained. As a result, the comparison reversed.

This shift is not a condemnation of a specific technology. It is a case where the conclusion changes when conditions change. Technology selection is not a search for a static correct answer. It is the work of re-examining where costs lie.

The React Native Decision Was Correct at the Time

Reporting by Nkzn on Zenn concludes that the 2020 choice was correct at the time. Shopify offers a similar retrospective. This is not about overturning a past decision.

The advantages at the time were clear. It reduced duplicate implementation. It increased the speed at which new features reached users. It broadened opportunities for web engineers to participate. It contributed to the productivity of the organization as a whole.

At the same time, burdens existed. Keeping up with updates to the framework itself. Managing the boundary with the native layer. Dependence on external libraries. Performance tuning. These were recognized from the outset.

Even so, the savings from eliminating two-track development outweighed those costs. That is why it was adopted. The criterion for judgment has been consistent. It is a comparison of the savings gained versus the costs paid. Only the terms of the equation changed between 2020 and 2026.

The Rise of Coding Assistance That Tipped

the Scales

At the center of the change is the practical adoption of coding agents. Shopify integrated them deeply into its development process. Referring to an implementation on one platform to generate the other. Aligning behavior through testing and review. Combining visual verification as well.

The cost of two tracks of native development has not disappeared. The burden still remains. But it is lower than in 2020. The effort of generation has decreased. Creating scaffolds has become faster. Automation of repetitive work has advanced.

On the other hand, costs on the React Native side persisted. Following the framework continues. Investigating boundary issues remains. Managing external dependencies remains. The need for performance tuning has not disappeared. Because only one side became lighter, the scales tipped.

Importantly, the effect did not come from introducing tools alone. Shopify invested in infrastructure. Setting up checkpoints. Building automated tests. Multi-system code review. Human approval. The design of the entire operation is the premise.

The Structure of Implementation,

Synchronization, and Quality Assurance Costs

The burden of two tracks of native development is not only code duplication. Reflecting specification changes becomes doubled. Verifying consistent behavior becomes necessary. Synchronizing bug fixes is also required. Operational burdens increase as well.

Consider, for example, a case where operating methods differ by platform. Guidance documents must be prepared separately. Training for support staff is also doubled. Handling inquiries from users becomes more complex. Costs beyond code accumulate.

Shared coding lowers implementation costs. The same business logic is written only once. The effect of reducing duplication is easy to see. It also overlaps with areas where automatic generation excels. Once the implementation on one side can be used to create the other, the relative advantage shrinks.

The effect of reducing synchronization costs is also large. With two codebases, consistency must be maintained. A missed fix may occur on only one side. Differences in interpretation can also arise. Within the scope that is shared, this risk is reduced. There are also implications for quality assurance costs. If shared business logic behaves identically, it becomes easier to prioritize testing. Resources can be directed to platform-specific areas. The pattern in which uneven quality management invites user distrust overlaps in part with the case discussed in Quality Management Gaps on Second-Hand Platforms and Risks in Young Consumers’ Rational Consumption. The importance of test design applies regardless of field.

The Reality of Remaining Costs at the

Abstraction Boundary

Sharing does not solve everything. Support for native APIs remains. Following OS updates remains. The work of updating the framework itself is newly added. Leaks from the boundary also occur.

When a leak occurs, low-level investigation becomes necessary. It is work that descends into the world of Swift and Kotlin. Checking device differences remains. There are also differences in lifecycles and screen rendering. Testing on only one side is not sufficient.

The move to develop language and infrastructure as one shares a common concern with the direction shown by Modular Platform Release and the Integration Vision for the Mojo Language and MAX Framework. The balance between the efficiency of the abstraction layer and the controllability of the lower layer is at issue. The perspective of choosing a language on the premise of descending to the lower layer also resonates with the evaluation in Developing GBA Games in Zig: Why It Is Ideal for Retro Embedded Systems. An attitude of estimating boundary costs is important.

Costs do not disappear. They only move to a different place to be paid. This understanding is the starting point for selection. Looking only at the sharing ratio does not reveal the reality. Updates, dependencies, investigation, and testing must be included in the comparison.

Investment in Development Infrastructure as a

Prerequisite

Shopify’s case cannot be directly applied to one’s own organization. The presence or absence of infrastructure investment divides the conditions. A chain of automatic generation, testing, review, and approval becomes necessary. Synchronization costs will not fall with the introduction of a single tool alone.

A system is needed to lower the cost of maintaining two tracks. Designing checkpoints. Introducing visual review. Review by multiple systems. Establishing operational rules. Without investment in these, a transition is difficult.

For small and medium-sized organizations, circumstances differ. Personnel are limited. Testing resources are also limited. In many cases, savings through shared code remain effective. For products with little platform-specific customization, the advantages remain. Conversely, for products with extensive advanced device integration, burdens increase. Assessment based on product characteristics is required.

Technology is a tool. If it is useful, it should be used. If it is no longer worth the cost, it should be abandoned. That judgment requires an understanding of the cost structure. Shopify’s article can be evaluated as teaching material that demonstrates that way of thinking.

Editorial Opinion

In the next 3 to 6 months, we expect more organizations to re-examine whether to continue sharing. In particular, we expect organizations that have already introduced automatic generation to move to calculate the actual measured cost of dual implementation. We assess that reviews comparing framework update costs and staffing composition will become routine.

In 1 to 3 years, we expect the unit of sharing to shift from entire screens to validation logic and design infrastructure. Even as accuracy of conversion between languages improves, we assess that responsibility for maintenance will remain. We see the ability to design a balance between uniformity of user experience and operating costs becoming a competitive advantage.

As the editorial team, we believe the question at issue is who bears synchronization costs. As machine-generated code increases, will the design of review and testing not become more important. Will whether implementation savings can be redirected to infrastructure investment not become the dividing line.

References

• “クロスプラットフォーム開発が解決するコスト、解決しないコスト”, by Nkzn — Zenn, 2026-09-12T14:05:10.000Z (ARR)
• Source URL: https://zenn.dev/nkzn/articles/cross-platform-development-costs-2026