"React because it's cheap" is no longer an argument

2026-10-19

The native vs cross-platform debate is over. There are no longer any wins in using React Native, Flutter, Kotlin Multiplatform or those web wrappers to gain a single code base. Previously, two native apps meant two teams, two implementations of every feature, two test passes and two release trains. Cross-platform tooling meant one team and one code base. Nobody claimed cross-platform felt better. It was simply cheaper, and "good enough" won the budget meeting.

That argument has expired. AI has changed what it costs to build and maintain native code, and we are now living in a new world. Today native no longer has to cost extra, so give your users the greatness they deserve.

Cheap ends up costly

The savings from cross-platform are real on day one but the bill arrives later.

Users notice. Scrolling, gestures, text fields and navigation that almost behave like the platform feels off, even when users can't say why. Apps that feel at home get better reviews and keep their users.
Missing sales. When buying goes hand-in-hand with the experience and you have gained user's trust, there will be more sales. Remove obstacles by giving users excellence.
The platform moves on without you. On-device AI, home screen widgets, Live Activities and the Dynamic Island all ship as native APIs first. Each one becomes a bridge to build, a plugin to wait for, or a feature you skip. Your tooling ends up deciding which features your users get.
The framework becomes a dependency. Bugs in the tooling show through in your product. Every OS release and framework upgrade is a project of its own.
Accessibility and performance take extra work. Native controls get VoiceOver, Dynamic Type and smooth animation for free. In a cross-platform layer you rebuild them, or you don't.

None of this was a secret. Teams accepted it because the alternative was paying for everything twice.

What changed: the duplicate work disappeared

The expensive part of native was never really the native code itself. It was doing everything twice: implementing each feature twice, testing it twice, documenting it twice, and keeping the two apps in step.

That is exactly the kind of work AI is good at. It is repetitive, well specified and easy to verify. Once a feature exists on one platform, AI can carry it to the other, write the UI tests for both, and flag where the two have drifted apart. The human work that remains is the part that matters: design decisions, platform details and review.

Option	Verdict	Why
Two native apps, the old way	Good but expensive	All work is done twice. Feature parity is close to impossible.
Cross-platform	Cheap, then costly	Users don't feel at home, and the tooling's bugs show through.
Two native apps with AI, cross-compile	The best of both	One shared code base for the logic. AI handles parity, tests and documentation.

In addition we can now transpile most of the code from Swift to Kotlin, making even the AI redundant. Swift is open source, so the foundation (all the business logic) compiles directly to Android - reducing even more differences.

The new team setup

A traditional app team needs six to nine people: designer, backend, iOS, Android, product management and someone to run the process. Most of the coordination between them is handoffs. Now teams can be just two senior developers who own the whole product, with AI supporting design, code, tests and documentation.

One feature, one logic path, two native apps. Business logic is shared, so iOS and Android behave the same and ship new features on the same day. There is no second implementation queue, and no platform is an afterthought.
AI as a delivery layer. AI builds UI tests which are then run on both platforms before every release. AI proposes translations with full context of the app, and humans review. Documentation stay current (automatically by the AI) as the code changes.
Humans stay in control. Clear review rules define what AI may change and what needs human approval. Nothing ships without a developer's review.
One language across the stack. Open up the backend by allowing micro-services in Swift and stricter rules around the API-contract. Then app developers who finds a problem can fix both the service and the apps in one go. Less handoffs and discussion. No more priority decisions for people who have a hard time getting all the details and nuances figured out.

Already on React Native, KMP or Flutter? We also convert existing cross-platform apps into native iOS and Android apps, using AI to replicate them screen by screen and converting existing code with UnitTests to prove their reliability. You keep what works and get native quality at close to cross-platform cost.

What it means for you

The point is not just a smaller invoice. It is what the freed-up people and time can do instead.

Polish the details that create loyalty. The animations, the haptics, the widget that gives immediate feedback at a glance. These are what users remember.
Use everything the platform offers. On-device AI, widgets and Live Activities become ordinary deliverables, not separate projects.
Build what never left the backlog. The freed up people can go into new features, new apps or new markets.
Spend less time coordinating. Fewer handoffs means a shorter path from idea to release. This is the true power of this setup, less communication and less room for errors and mistakes.

Team size still depends on product risk and scale. Two developers is the operating model, not a rule for every product. But for most apps, "we can't afford native" is no longer true.

Try it on one feature

You don't have to bet the whole product to find out. Start small, and take the next step only when the last one has proven itself.

Workshop: we start with a workshop on how to streamline the workflow and what actions will benefit the most. Together we map platform gaps and release checks. You will need to prepare the answer to the question: "What will we do with all our extra time?"
Pilot: bring us in to stake out one shared feature path and give you a few options on how a new team setup could look like. We can optimise the build process, cleanup the project setup, place guidelines for automated tests and documentation.
Expand and continue: keep us on as an ongoing partner to keep the process running smoothly and to tackle new obstacles. We scale up as your needs grow.