GUIDES
Native (Swift/Kotlin) or Flutter/React Native?
THE SHORT ANSWER
For most businesses that want a serious mobile app, native development in Swift and Kotlin is now the better choice. The main advantage of Flutter and React Native was writing the code once instead of twice; with AI tooling the second platform costs far less than it used to, while native's advantages are unchanged.
Let me be clear about what suits me from the start: I build native apps in Swift and Kotlin. That is why you'll also find below the cases where I tell you not to go native, and the part where native genuinely costs more. Judge for yourself.
The difference in plain terms
Native means the app is written with the tools the platform's own maker provides: Swift and SwiftUI from Apple for the iPhone, Kotlin and Jetpack Compose from Google for Android. Two apps, each in the language of its own phone.
Cross-platform means one shared codebase that runs on both. The two well-known tools are Flutter (Google's) and React Native (Meta's). Between your code and the phone sits an extra layer that translates.
| Native | Cross-platform | |
|---|---|---|
| Code | Separate for iOS and Android | One shared codebase |
| Appearance | The real components of each phone | Drawn or mapped by the framework |
| New iOS/Android features | From day one | When the framework supports them |
| You depend on | Apple and Google | Apple, Google and the framework |
Why cross-platform was the right call until recently
The argument was simple and correct: the most expensive thing in a project is developer hours. Two native apps meant, roughly, doing the same work twice.
For a business that wanted to test an idea, one shared codebase was often the only realistic option. You accepted a slightly worse user experience and saved half the budget. A sensible trade, because the alternative really did cost a great deal more.
What AI changed
Here's the counter-argument before you think of it yourself: AI writes Flutter faster too. True. If everything speeds up, why would the comparison change?
Because AI doesn't help equally everywhere. It is excellent at translating from one shape into a similar one, and considerably weaker at inventing something from nothing. Porting a screen from SwiftUI to Jetpack Compose is exactly translation: the two languages have near-identical syntax and the two UI toolkits share the same philosophy.
So: on Flutter, AI speeds up the first half of the work — as it does for everyone. On native it disproportionately speeds up the second half, which was the only reason not to choose it.
That doesn't mean the second app falls out of a button. The developer reviews, adapts to the platform's conventions and tests. It needs clean architecture, a shared data and API design, and somebody who knows both platforms well enough to catch the differences. With those in place, the second platform is no longer "another 100%".
What you gain with native
New capabilities are there on day one
Every year Apple and Google ship new tools and new design. A native app gets them as soon as they're out. A cross-platform app waits for the framework.
The most recent example is the Liquid Glass design: Apple showed it in June 2025 and shipped it with iOS 26 that September. As of October 2026, a year later, Flutter still doesn't have it — the team isn't currently accepting contributions for Apple's new design and plans to rebuild the relevant components in a separate package, realistically by the end of 2026. In the meantime, anyone who wants their app to look like a 2026 iPhone either builds it themselves or relies on third-party packages. A SwiftUI app got it with one build.
This isn't a question of taste. It's a year in which your app looks dated next to every other one on your customer's phone.
The app behaves the way the user expects
People on iPhone and people on Android have different habits: how they go back, where they expect menus, how the phone feels in their hand. Native tools use each platform's real components, so the app sits naturally. Your user won't tell you "this is Flutter"; they'll say "something about it feels off" — and it will show in the reviews and in how many of them stay.
Speed, battery, size
Without an intermediate layer the app opens faster and moves more smoothly. On a simple app the difference is small and not worth paying for. On lists with a lot of data, maps, the camera or image processing, it is noticeable.
The whole phone ecosystem
Home-screen widgets, Apple Watch and Wear OS, Siri, CarPlay and Android Auto, NFC, health data, AI that runs on the device. In native these are a normal part of the work. In cross-platform most of them need native code anyway — at which point "one shared codebase" stops being one.
Fewer dependencies, less risk
A native app depends on Apple and Google. A cross-platform app depends on the framework and on the community's plugins as well.
That sounds technical, but it's a commercial risk: a plugin whose author abandons it can hold you back on an update that has to ship. For an app that will live for years, that matters.
Accessibility and security, ready-made
Screen readers for people who can't see, large type, Face ID, storing credentials in the device's secure element: in native these are built in and tested by the platform maker. If your app holds sensitive data — health, payments, identity — that counts double.
What costs more, honestly
Not to gloss over it: with native you maintain two apps. A bug is fixed twice and a new feature is written twice, even if the second time is far cheaper than the first. That cost is real and doesn't disappear.
In exchange you don't live through the framework's major upgrades, which every few years force whole apps to be rewritten. Which of the two costs less depends on how many years your app will live. The more years, the more it tilts towards native.
Kotlin Multiplatform: the third road
There is a middle path, and it is often the best one. With Kotlin Multiplatform you share the app's logic — the data, the rules, the communication with the server — between iOS and Android, while everything the user sees and touches stays native: SwiftUI on the iPhone, Jetpack Compose on Android.
You keep native where it shows, and write once where it doesn't. Together with the screen porting described above, it is usually the most efficient option for a serious professional app with a lot of logic behind it.
When to choose Flutter or React Native
Cross-platform isn't wrong. It just fits fewer cases than it used to. It is the right choice when:
- Your team already knows it. If you have in-house Flutter or React developers, their knowledge is worth more than the theoretically better technology.
- The app is mostly forms and lists, with no particular need for the camera, sensors or widgets, and you want it to look identical everywhere because your brand demands it.
- It's a prototype or an internal tool that will live a few months or be used by ten employees.
- You need a web version too from the same codebase, and you accept the compromises.
How to decide
Three questions, in order:
- Is the app your product or a tool? If the business rests on it, go native. If it's supporting, cross-platform is enough.
- How many years will it live? Under two, cross-platform is cheaper. Over three, native usually comes out ahead.
- Does it need anything from the phone? Widgets, a watch, NFC, the camera, notifications with logic. If so, native gives it to you without workarounds.
And a fourth, worth as much as the three together: start with one platform. Ship where most of your customers are, see whether they use it, and move to the second once it has proved itself. Today that second step is cheaper than it has ever been — and that, in practice, is the whole story.
What each one costs, I break down here: How much does a mobile app cost?