When requesting smartphone app development estimates, one explanation almost always appears: "Because iOS and Android can be built from a single codebase, it is cheaper than building them separately." For roughly the past decade, this premise has guided client decision-making.
On September 10, 2026, Shopify announced that it transitioned its flagship Shop app from React Native back to native Swift and Kotlin implementations. This comes from a company that used React Native for over five years and openly shared its journey.
Crucially, the reason was not that React Native failed. Shopify itself explained that the app prior to migration was fast and stable. What changed was not technical superiority, but the economic assumptions behind cost estimates.
The published figures
From the published information, we highlight details that influence business decisions.
- From validation to app store release took 12 weeks (with an initial core of six engineers, later joined by individual feature teams)
- Session stability improved from over 99.5% to over 99.95%, explained as a ten-fold reduction in crashing sessions
- The migration was enabled by advancements in coding agents. Using the existing React Native implementation as a reference, agents could handle implementation, testing, and review for both Swift and Kotlin
While the 12-week figure tends to gain attention on its own, this was a re-implementation starting with an already working, finished product in hand. Specifications were finalized, a reference implementation existed, and expected test outcomes were known. Conditions are entirely different from building from scratch.
This is the migration demo for the Shopify app published by the company. Separate from the Shop app released in 12 weeks, it illustrates the process of breaking screens into small, verifiable units for implementation. Source: Shopify Engineering, "Back to Native".
The benefits of shared code and the cost of maintaining two stacks
Why was the single-codebase approach chosen in the first place? One primary reason was the ability to share implementation.
Because you do not have to build the same feature twice.
Build a screen once, and it runs on both platforms. Fixes only need to be made once. A single language suffices for engineers. The ability to eliminate this "build-twice cost" outweighed the overhead of maintaining the cross-platform framework for Shopify at the time.
What Shopify's announcement highlights is that AI reduced the denominator of this premise. With a reference implementation available, agents can handle implementation in the second language. Consequently, the cost of building twice is no longer as substantial as it once was.
Do not dismantle what remains intact
This is the single most critical point for clients commissioning work. What agents made cheaper is the implementation phase; app development costs comprise far more than just coding.
Consider the costs that have not become cheaper:
- Defining specifications. Humans determine what to build. If building two native apps, platform-specific behavioral differences must also be decided
- Architecture and review. People are required to read generated code and evaluate its validity. In fact, as code volume grows, the review workload increases
- App store review and releases. App store submissions, certificate management, and release procedures remain separate workflows per platform
- Post-release operations. Bug reports arrive across two separate stacks, increasing the effort required to isolate which platform is affected
- Staffing. You need an organization capable of overseeing both Swift and Kotlin. Even if agents write the code, human reviewers are indispensable
In short, the cost of building two apps did not drop to zero; rather, the share of implementation within total expenses decreased. This shift has the greatest impact on projects where coding represented the bulk of expenses, while having a much smaller impact on projects where it did not.
Decision criteria differ by scale
Whether Shopify's decision directly applies to your company depends on your project's scale.
Internal business apps with few screens and updates only a few times a year. Staying cross-platform remains completely appropriate. There is virtually no rationale for maintaining two stacks beyond implementation cost. In fact, increasing operational pipelines works to your disadvantage.
Customer-facing apps where UI fluidity directly drives user experience. Evaluating native development makes sense here. However, your decision criteria should not be "because AI made it cheaper," but rather what specific capabilities cannot be achieved currently. If you cannot identify unfulfilled requirements, that alone is not a reason to rebuild.
Does it need to be a mobile app in the first place? If web technologies suffice but you are packaging them into an app, the choice should not be about programming languages. Pitfalls of WebView wrapper apps are covered in Overlooked trade-offs and alignment scope for WebView apps. When commissioning work, this should be read first.
The overall process for outsourcing is detailed in Guide to outsourcing internal mobile app development, while cross-platform technology selection is summarized in The scope of full-stack development with Flutter.
Three questions to ask when reviewing an estimate
When technical architecture comes up, verify the following points. They are structured so anyone can ask them without deep technical knowledge.
- "Is this architecture chosen for cost savings, or for the desired user experience?" If cost is the justification, ask them to provide quotes for building two native apps side-by-side. The difference is sometimes smaller than expected
- "After release, will there be cases where fixes are applied to only one platform?" If they answer yes, it is no longer truly handled with a single codebase. You can uncover operational realities early
- "If AI is compressing implementation hours, who conducts code reviews?" If an estimate assumes accelerated coding, review staffing should be clearly documented. If omitted, review work is effectively assigned to no one
What to do next
For the app you are currently planning, write down the number of screens and projected update frequency in the first year following release.
Even with few screens and infrequent updates, costs vary based on reliance on native device capabilities and available maintenance personnel. First check whether existing architectures meet your requirements, and compare that against the additional cost of migration.
Conversely, if you anticipate many screens and continuous updates, designing who will continue maintaining them matters far more than implementation architecture. Rather than adopting decisions made by tech giants in the news, quantifying your own update frequency is far more useful for comparing estimates.
GleamHub provides consultations on custom development, AI, and automation, covering architecture selection for mobile apps, evaluating whether to rebuild existing apps, and designing AI-assisted development pipelines. Because approaches depend on project scale and operational setups, please reach out via Contact Us.
Sources
- Native is now the future of mobile at Shopify (2026) — Shopify Engineering
- Migrating Shop app from React Native to native (2026) — Shopify Engineering
- Shopify spent years on React Native — then rebuilt everything in 12 weeks — The New Stack
- Five years of React Native at Shopify (2025) — Shopify Engineering
