One app or two? What AI changed in your mobile channel decision

Picture the committee meeting where the new app for your customers is approved. Two proposals are on the table. The first says: "One codebase for iPhone and Android; build it once and save almost half." The second says: "Two native apps, one per platform; that is the serious choice for a bank or an insurer." Each proposal comes with its famous case. One cites Shopify, which built its apps on a single codebase and made it work. The other cites Airbnb, which abandoned that same technology in 2018.

Until recently, the committee would have chosen whichever case sounded better. But in September 2026 Shopify, the example behind the first proposal, announced that it is going back to native [3]. It did not leave for the same reasons as Airbnb: its context was different, and its reason has to do with artificial intelligence.

This article is for whoever signs that decision: general management, IT, sales or digital. It is not a technical question. It is a decision about total cost, speed, phone capabilities, team and risk, and its assumptions expire.

First, three words

Before comparing, everyone at the table should understand the same thing.

• Native: you build one app for iPhone, with Apple's language and tools (Swift), and another for Android, normally in Kotlin, the language Google recommends for Android. That is two codebases and some duplication. In exchange, each app adopts the phone's capabilities directly as they become available.
• Cross-platform: you write a single app and an intermediate layer makes it run on both systems. The best-known examples are React Native (born at Facebook, programmed in JavaScript, the language of the web) and Flutter (from Google). One codebase, one team, but one more layer between your app and the phone.
• Shared logic, native screens: the middle ground. You share what cannot be seen (business rules, calculations, the connection to your systems) and each platform draws its own screens. The most visible example is Kotlin Multiplatform, from JetBrains, which Google officially supports for sharing logic between Android and iOS [5].

And four terms that will come up. Framework: the development platform on which the app is built. Dependencies: third-party components the app uses and that must be updated and monitored. Bridge or layer: the code that translates between the shared part and the phone's functions. New Architecture: the rebuilt way in which React Native does that translation.

Two companies, different contexts, similar result

Airbnb, 2018: it did not work for them

Airbnb integrated React Native inside its native apps, which were already large and kept growing. In June 2018 it announced that it would stop using it [1]. Its reasons, in business language:

• It did not share as much as expected. Only a small part of the app was in React Native, and connecting it to the rest required a lot of bridge infrastructure. It ended up, the article says, maintaining code on three platforms instead of two [1].
• Fixing failures became harder. Building was faster; debugging was much worse [1].
• Expertise was scarce, inside and outside the company, to solve the technical problems they ran into [1].

The nuance almost nobody cites: the article itself says that many of those difficulties came from the hybrid model they chose, and that 63% of its engineers would choose React Native again (with the bias, which they themselves point out, that they only surveyed people who had used it) [1]. And today it carries a notice at the top: it reflects the technology of late 2017, and it asks: "If these articles are exclusively cited as a reason not to use React Native, please do more research of your own before making a decision" [1].

Airbnb did not say "React Native is no good." It said: "the way we used it, with our team and our app, we did not reach what we were looking for."

Shopify, 2020–2025: it worked for them

Shopify decided in 2020 that its new mobile apps would be built in React Native. In January 2025, a Shopify engineering director published the five-year review [2]: "Not having to build the same features twice has given us a step change in productivity." It reported screens that load in under half a second and more than 999 of every 1,000 sessions without crashes, and that native does not automatically mean fast, nor React Native automatically slow [2].

The same article carries the warnings a director should read [2]:

• Using React Native 100% was meant to be an anti-goal: they still needed native code for the newest hardware features (2D and 3D scanning, AI models that run on the phone), for home-screen widgets, the watch and voice shortcuts, and for long background tasks, such as the synchronization that lets their point of sale take payments without a connection.
• Upgrading the app to each new version of the framework takes a significant amount of work, and dependencies have to be kept up to date.
• Debugging was still unstable.

In other words: it worked for them, with a team that also actively contributed to the React Native ecosystem.

Shopify, 2026: it worked, and they are still going back

On September 10, 2026, the same author published "Native is now the future of mobile at Shopify" [3]. The core reason fits in one sentence: "LLMs changed one of the core assumptions behind our 2020 decision" [3]. An LLM is a language model, the technology behind the AI assistants that now write code.

The assumption was that building each feature twice, in Swift and in Kotlin, was too expensive. Shopify says that, with AI agents (assistants that carry out programming tasks on request) doing implementation, translation, testing and review work, that cost stopped being the deciding factor [3]. What remains are the advantages of native: being closer to each platform's capabilities and to the manufacturer's tools, with fewer framework layers and dependencies in between [3]. And it clarifies: it is not leaving because React Native is slow; its apps, it says, are fast [3].

The result it reports: its shopping app (Shop) went from proof of concept to published in native in 12 weeks; the merchant app would ship before the end of 2026 [3].

The lesson is not "let's go native"

Put the two cases side by side:

Different contexts, similar result. If your committee copies the choice of either one, it copies a conclusion whose assumption may not apply to your company. What you should copy is the method: review from time to time the economic assumption on which the decision was made.

What AI changed, and what it did not

Shopify states that, for its apps and its team, AI lowered the cost of writing the same feature twice, and clarifies that maintaining two platforms still costs [3]. In your company, validate that with a limited trial before taking it for granted. And even where that cost goes down, everything else stays the same, or comes down much less:

• Designing the experience, deciding what the app does and what it does not.
• Testing on dozens of phone models and operating system versions.
• Reviewing whether the generated code is maintainable. Shopify says it bluntly: pointing a language model at all its code to "translate" it produced an enormous amount of unmaintainable code [3]. To avoid that, it built its own staged system, with tests, visual review, two automated reviewers and human approval [3].
• Publishing in the Apple and Google stores and meeting their rules.
• Connecting the app to the systems that actually serve the customer. We will come back to this below, because it is often the most expensive part.

In other words: AI did not make having two apps free. It made the cost of writing twice stop being, for Shopify, the deciding factor. Whether it is in yours depends on how much quality control you can put over the generated code.

Nor is there a universal winner in performance. A study published in September 2026 (a preprint, that is, not yet peer reviewed) built the same app five times: native iOS, native Android, Flutter, React Native and Kotlin Multiplatform, and measured each variant 2,000 times [4]. Native recorded the lowest times in the non-interface part; Kotlin Multiplatform was the closest shared option; in those implementations, the shared ones had less code than the two native ones combined, which is not the same as the effort of any given product. Its conclusion: no technology is superior at everything; the advantage depends on which attribute is measured, on the workload and on the platform [4].

Five criteria to decide

1. What in your roadmap touches the inside of the phone?

List what your app will do over the next two or three years and mark what depends on the hardware or the operating system:

• Biometrics: fingerprint or face to sign in or authorize an operation.
• NFC: paying by tapping the phone, or reading a credential or card.
• Advanced camera: reading IDs, documents or codes; scanning damage for a claim.
• Background work: synchronizing, taking payments without a connection, tracking a delivery.
• Widgets, watch, voice shortcuts, rich notifications.

If the list is short, a cross-platform app handles it well and uses targeted native pieces where needed. If the list is long and is the heart of your value proposition, native lets you adopt each new Apple or Google feature with fewer layers. Shopify, even in its best years with React Native, kept native code precisely for this [2].

2. What team do you have, and what team can you retain?

A team strong in web development moves fast in React Native. A team with iPhone and Android specialists gets more out of native. Airbnb cited the lack of expertise as part of its problem [1]; Shopify, with a mature team, made both options work. The question is not which technology is better, but which one your team can sustain for five years, including the vacancies it will have to fill.

3. What does your customer prioritize?

Getting to market first and with the same experience on both phones, or the most polished feel, the most immediate response and the smallest app size. For a content or catalog app, the former usually weighs more. For an app where the customer moves money several times a day, the latter weighs more than it seems.

4. What does it cost to maintain, not to build?

The cost of building is visible in the proposal; the cost of maintaining shows up later. With cross-platform you have to keep pace with the framework and its dependencies. A recent example: React Native made its New Architecture the default in version 0.76, in 2024, and since 0.82, in October 2025, it can no longer be turned off [6]. An app that upgrades to 0.82 without having validated it may require compatibility work and testing: budget for it. With native you have to sustain two codebases and keep them identical. AI changes the weight of this second cost; it does not eliminate the first.

5. How often do you review the decision?

Shopify made a good decision in 2020 and another good, different one in 2026, because an assumption changed. Put a date in the minutes: which assumption supports the choice (for example, "building twice costs almost double"), how it is measured, and when it will be reviewed again.

The middle ground: share logic, not screens

Between "one app" and "two apps" there is a third way that often suits regulated companies: share what cannot be seen and build natively what can be seen.

Think of what must be identical on iPhone and Android: how a premium or a fee is calculated, which validations apply to a transfer, how information is stored and encrypted, how your systems are called. If those rules live in two codebases, the risk grows that they say different things. With Kotlin Multiplatform, for example, those rules are written once, and each platform draws its screens with its own tools. Google officially supports it for sharing business logic between Android and iOS, and lets you choose how much to share: from just the logic to the entire application [5]. In the study cited, it was the shared option closest to native in performance [4].

Its cost: the team must master both platforms and, in addition, the shared layer. It is not the cheapest option; it is the one that usually delivers parity of rules without giving up the native experience.

Situation and the option that usually fits

A conversation guide, not a recipe.

Scenario (illustrative figures, no client). An insurer plans its app for three years: 24 features. When marked, 5 depend on the inside of the phone (camera for claims, biometrics, rich notifications, the adjuster's work without a connection and a policy widget). The other 19 are lookup and transaction screens that call its systems. The 5 of 24 is an inventory, not a verdict: each of the 5 is weighed by criticality, dependence on an SDK (a third party's kit, such as an anti-fraud one), regulatory obligation and performance. A single critical feature can decide: if the adjuster's work without a connection is the business's bet, it weighs more than the 19 and the balance tips to native or shared logic. In any case, the 19 screens depend on the systems behind them responding: that is where most of the risk lies.

The risks, in business language

Any of the three options has risks. Five for the table.

• "The framework changed and we have to migrate." A cross-platform app depends on a third party's pace and on many dependencies. Shopify describes upgrading to each version as a significant amount of work [2], and the New Architecture requires compatibility work from anyone who upgrades without having validated it [6]. Budget for maintenance, not just construction.
• "We do not know why it fails." More layers between your code and the phone mean failures that are harder to find. Airbnb lived it [1] and Shopify was still reporting it in 2025 [2]. In an app that moves money, the time to find a failure is time with annoyed customers.
• "AI wrote it and nobody reviewed it." Generating two apps with AI is cheaper; generating two unmaintainable apps is too. Shopify's move back to native came with controls at every stage [3]. If your vendor proposes "two native apps because AI builds them," ask how they control the quality of what the AI writes.
• "On Android it does one thing and on iPhone another." With two native apps, parity is not automatic: the risk grows that a rule changes in one and not in the other. Decide what must be identical (rules, amounts, legal messages), which source is the authority, and back it with contracts and parity tests between both apps. Leave on the phone only what the experience or work without a connection requires.
• "The app is ready, but the core is not." The most frequent risk and the least discussed. We treat it separately.

The app is the face; the hard part is behind it

In committee, the debate is usually one app or two. But the customer does not judge the app's technology: they judge whether their payment was applied, whether their policy shows up, whether their balance is right. All of that is decided by the core system and the integrations that connect it to the app.

A flawless app, native or cross-platform, that queries a slow core or that only gets a "received" when the customer expects a "done," is perceived as a bad app. That is why the mobile channel decision comes with others:

• What the app does and what your systems do. The rules that must be identical across all channels (app, web, branch, advisor) should have their authoritative version in the systems behind the app, defined once; in the app, only what is necessary.
• How it integrates with the core. Which queries go online and which operations go with a reference number and follow-up. That is the topic of the article "Online or asynchronous? How to choose how to integrate your systems".
• What happens when the back-end system does not respond. What the customer sees, what is stored on the phone and how it retries without duplicating a payment.

If the integration is well resolved, changing the app's technology, as Shopify did, is a channel project. If it is not, any change of app drags the back-end problem along with it.

Five questions for your next committee

1. What percentage of our mobile roadmap depends on the inside of the phone (biometrics, NFC, camera, background, widgets), and how much is screens that query our systems?
2. What team can we sustain for five years, including vacancies, for the option we choose?
3. What economic assumption supports our current decision, and when did we last measure it?
4. If we use AI to build, how do we control the quality of what it generates before it reaches production?
5. Where does the single version of the rules that must be identical live on iPhone, Android and the other channels?

If on two or more the answer is "I don't know," that may be where your risk is.

Where to start this week

Take your app's roadmap and mark each feature with one of two labels: "touches the inside of the phone" or "is a screen on top of our systems." Count how many there are of each and flag the critical ones. That inventory, plus the team you have, tells you more about the option that fits than any famous case.

What Hábil does

Hábil is a Mexican engineering consultancy, founded in 2006, that designs and builds digital channels (web, mobile and desktop apps) connected to the systems a company already has. We do not arrive with the technology chosen: we help decide between native, cross-platform or shared logic according to your roadmap, your team and your systems, and we build with the option that fits. See the page Digital channels your customers actually use.

The first conversation is at no cost: it starts from your mobile roadmap and from how it will connect to your current systems. Write to us on WhatsApp.

Statements about companies reflect their publications as of October 13, 2026; they are each company's declarations, not our own measurements.