Native vs cross-platform mobile apps: how to choose in 2026

Why mobile apps went cross-platform

The cost of building every feature twice

A mobile app lives on two systems, iOS and Android, which use neither the same language nor the same tools. Apple has apps written in Swift and Google in Kotlin, so a so-called native app exists in two versions, each written separately, that must do exactly the same thing. Every new feature is developed twice and tested twice. The two versions also drift apart as soon as one falls behind the other, and the company then spends part of its time closing those gaps instead of moving its product forward. For a project launching its first app, this doubling weighs on the budget, the timeline and the number of people who need to be brought together.

React Native and Flutter, one codebase for iOS and Android

Cross-platform frameworks answer this cost. React Native, released by Facebook in 2015, and Flutter, launched by Google in 2018, make it possible to write a single app that runs on both systems. The first relies on JavaScript and the React ecosystem, which opens mobile development to web developers. The second uses its own language, Dart, and its own rendering engine. In both cases, the company accepts an extra layer between its code and the phone, with a little more weight and some distance from each platform's own features, in exchange for a single codebase. For nearly ten years, a large part of the market considered this a reasonable trade, from startups to large corporations.

Shopify's bet on React Native in 2020

Shopify became the most cited example of this choice. In 2020, the company announced it was moving entirely to React Native, then migrated its existing apps over the following years. It gave three reasons, no longer building every feature twice, letting its developers work across the whole technical stack, and spending less time closing gaps between iOS and Android. Six years later, its head of mobile considers that the bet delivered on all three. Yet the three reasons concern a single cost, that of building twice, and this is the variable that AI agents have since shifted.

What Shopify's return to native changes

On 10 September 2026, Shopify published two posts on its engineering blog, one explaining its decision to return to Swift and Kotlin, the other detailing the migration of its Shop app. The announcement circulated widely, because it came from the company that had championed React Native most strongly and because it attributed the reversal to AI. Read closely, however, it says something more measured than most commentary took from it.

The 2020 assumption that AI agents have shifted

Shopify has no complaint about React Native. Its apps were fast and stable, and the company says so. The change concerns the cost of writing the same feature twice. Its developers have used language models since 2021, and these models can now implement a feature on Android using the iOS version as a reference, and the other way round. They also help a developer work in a language that is not their own, and make it possible to keep both platforms aligned through shared specifications, tests and checkpoints.

The company remains cautious about the scope of this change. It writes that native still means building and maintaining two pieces of software, that this cost has not disappeared, and that it has simply stopped being the deciding factor it was in 2020. A single assumption has therefore shifted, the one that tipped the balance towards cross-platform, while the advantages of native, closer proximity to each system and its tools, remain in place.

Measured gains on the Shop app

Shop, Shopify's shopping app, was the first to be rebuilt. According to the company, it took twelve weeks to go from a proof of concept to a native app released on the stores. Its timeline shows a beta opening in mid-July, then a final release at the end of August, after security testing. The figures it published give an idea of what it gets in exchange for two codebases. App start-up is 23% faster on iOS and 50% faster on Android, the share of sessions ending in a crash has been divided by ten, and the Android app is 109 MB lighter, more than a third of its size. On iOS, the size stayed the same.

For an app used by hundreds of millions of customers, these gains justify maintaining two codebases. What remains to be seen is what AI actually reduced in the cost of this migration, and what it left untouched.

What AI reduces in the cost of an app, and what it leaves

The cost of a mobile app is spread across several items, of which writing the code is only one, and AI does not act on each with the same force. The Shop migration makes it possible to measure this, because Shopify published how the project unfolded as well as its results.

Writing and translating the code

This is the item on which AI has the greatest effect. Before committing, Shopify gave a single engineer a one-week trial with agents, to rebuild as much of the existing app as possible in SwiftUI. The result was not production-ready, but it was enough to show that a screen-by-screen migration was realistic. The agents ported features, built screens, wired up data and reproduced animations, with an efficiency the company attributes to their having an existing implementation to guide them.

Even here, Shopify points out that handing all the React Native code to an agent is not enough to get a native app. According to the company, that approach produces a large amount of code that cannot be maintained or shipped. It therefore built Helix, a system that breaks each screen into small steps and only allows the next one once tests have proved the behaviour and the rendering has been compared with the original app.

Architecture decisions

AI can write the code for any architecture. It builds what it is asked to build, and falls back on a default solution when nothing specific is requested, as we showed in our article on building a SaaS. The choice between native and cross-platform, where the app's logic lives and how it communicates with the server are decided before the first line of code, based on the project's constraints. Shopify, for its part, made its decision by reassessing its own constraints, and its agents came in once that choice was settled.

Testing, security and app store releases

The timeline Shopify published shows how much room these stages take. Building the foundations and features takes up May, June and July. From mid-June, the teams responsible for each part of the app come in to test their area and fill the gaps. A beta opens in July and runs until the release at the end of August, and penetration testing takes up August. The migration also had to look like an ordinary update, without users having to log in again or losing their notifications, and every interaction had to keep sending the events that other systems, such as recommendations, depend on.

These stages depend on people who know the product, on real users and on security requirements. Agents contribute to them, but they take roughly as long as before, and with native, every release has to go through review twice, once with Apple and once with Google.

Keeping iOS and Android in step over time

Once the app is launched, the doubling continues. Shopify has made it a rule that the iOS and Android versions always have the same features. React Native enforced this parity through its shared codebase, and the company now enforces it through its development and release process. This cost is paid with every change, throughout the life of the app. AI cuts the time needed to write the second version of a feature, but both versions still have to be tested, released together and fixed for the problems specific to each.

Why the numbers favour native at Shopify

In short, AI sharply reduces one item and leaves the others almost unchanged. For native to become attractive despite this, those other items have to be absorbed, and Shopify met three conditions that allowed it to do so.

An existing app to serve as a model

Shopify chose to rebuild everything rather than migrate gradually, partly because models efficiently build a feature in Swift or Kotlin from its React Native version. The existing app acts as a complete specification, in which every screen, every behaviour and every event already exists and can be used for comparison. A new project has no such reference. It must first decide what the app will do, and that stage remains the longest.

Five years of practice and tooling around AI agents

Shopify has used language models in development since 2021, a year before ChatGPT came out. For this migration, the company built Helix, but also Tardis, a tool that gives agents structured access to the events, logs and state of the running app. These tools exist to give agents the context they lack, a question we approached from another angle with the shared memory of our own agents. It even reworked the architecture of its apps so that their logic could run without an interface and agents could test it in milliseconds rather than minutes. The whole effort was carried by a dedicated mobile team of six engineers, joined along the way by the product teams. This tooling is therefore a project in its own right, one that few companies can fund for a single app.

A React Native overhaul it had to fund anyway

For Shop, the decision coincided with another heavy investment, adopting React Native's New Architecture, which would have forced the team to rework native modules, rendering and the boundary between shared code and platform-specific code. Against native, the alternative was therefore another costly overhaul. Removing just one of these three conditions is enough to change the outcome.

Business logic, the hidden cost of two apps

One last item shows up less in Shopify's figures, though it weighs heavily over time. It has to do with business logic, meaning the rules that decide what the app does and how it does it.

Two apps talking to the same server

A mobile app carries part of this logic. It validates what the user enters, keeps track of the session state, syncs data with the server and handles errors. With native, this logic exists twice, once in Swift and once in Kotlin. Every change on the server has to be carried over to both, and the slightest discrepancy produces two apps that react differently to the same response. These discrepancies often look like server problems, so people look for them in the wrong place. And since not all users update their app, the server also has to accept several versions of each app at once, released at different paces.

Where to put a mobile app's business logic

Three architectures come up most often, and they differ in how many times this logic is written.

     iPhone              Android
+---------------+   +---------------+
| Interface     |   | Interface     |
| SwiftUI       |   | Compose       |
+---------------+   +---------------+
| Logic         |   | Logic         |
| Swift         |   | Kotlin        |
+-------+-------+   +-------+-------+
        |                   |
        +---------+---------+
                  |
                  v
               Server

  Interface x2   Logic x2

     iPhone              Android
+---------------+   +---------------+
| Interface     |   | Interface     |
| SwiftUI       |   | Compose       |
+-------+-------+   +-------+-------+
        |                   |
        +---------+---------+
                  |
        +---------+---------+
        | Shared logic      |
        | Kotlin (KMP)      |
        +---------+---------+
                  |
                  v
               Server

  Interface x2   Logic x1

+-------------------------------------+
| Interface and logic                 |
| React Native, Flutter or            |
| Compose Multiplatform               |
+------------------+------------------+
                   |
          +--------+--------+
          |                 |
          v                 v
       iPhone            Android
          |                 |
          +--------+--------+
                   |
                   v
                Server

  Interface x1   Logic x1

With separate native apps, the logic is written twice. With Kotlin Multiplatform, it is written once in Kotlin and shared between the two apps, which each keep their native interface. With cross-platform, interface and logic are written once. Shopify, for its part, separated its logic from the interface to make it testable by its agents. For another app, the question comes down to where the logic lives. The more it stays on the server, with lightweight apps that display and relay, the more native becomes an option. The more rules the app carries locally, to work offline or run its own calculations, the more sharing that logic matters.

Native or cross-platform, how to decide for your app

Shopify's decision therefore offers no ready-made answer for other apps. What it provides is a method, which consists of going back over each cost item and seeing which ones the project can absorb.

The project's budget and timeline

Maintaining two native apps means funding two codebases for the whole life of the product, and bringing together skills on both platforms. As with a website, it is often the architecture decisions made at the outset that set this cost over time, a mechanism we covered in detail in our article on the cost of websites. A project that needs to ship quickly, or that first wants to check its app will actually be used, saves time with a single codebase. It can always revisit that choice when usage and revenue justify it, as Shopify did after six years of React Native.

What the app does and how it will evolve

An app that integrates deeply with the phone, with widgets, a smartwatch version, voice shortcuts or demanding animations, gets more out of native. A booking, loyalty, ordering or account-tracking app less often gains a benefit its users would notice. How the app will evolve also matters. An app that gets new features every month pays for the doubling with every release, whereas a stable app pays for it mostly at launch.

Where AI fits in a small company's calculation

AI changes several things for a modest project. A native prototype on both platforms becomes realistic in a short time, porting a feature from iOS to Android costs much less than it used to, and a cross-platform app can more easily include a native module when a feature requires one. It leaves testing, releases, long-term parity and architecture decisions to the project, however. The calculation is therefore made item by item, according to what the company can carry, and its conclusion may change over the life of the app.

At Nualt

We build our web projects with React and Next.js, and Expo, which is built on React Native, extends that foundation to mobile. An app and a website can then share part of their code, such as data validation or server communication. Before writing a single line, we go through the items described in this article with the project owner, what the app needs to do, where its logic should live, its timeline and its budget, to choose the approach that suits it. As with our other projects, the code, the developer accounts and the documentation belong to the client, who can develop their app further with us or without us.