Every few months a founder or product head asks us the same question: should we build in Flutter, React Native, or go native? The honest answer is that all three are good choices in 2026, and teams lose more money picking the wrong one for their situation than they would ever save by picking the "best" one in general.
We build native Swift and Kotlin apps and Flutter apps, and we have rebuilt apps that started on one approach and outgrew it. This guide is the conversation we have with clients before we write a line of code.
The short version
| If your app is mostly... | Start with |
|---|---|
| Forms, lists, dashboards, commerce, booking or content | Flutter or React Native |
| A product where the team already lives in React and TypeScript | React Native |
| A branded UI that must look identical on every device | Flutter |
| Camera, video, Bluetooth devices, AR or on-device AI | Native Swift and Kotlin |
| An existing native app you want to extend without a rewrite | Kotlin Multiplatform for shared logic |
| A regulated app (banking, health) with strict security reviews | Native, or cross-platform with native security modules |
What actually changed in the last two years
A lot of comparison articles online are still arguing about problems that were fixed in 2024 and 2025. Three changes matter.
React Native dropped its old bridge. The New Architecture, which lets JavaScript talk to native code directly through JSI instead of passing serialised messages, became the default in version 0.76. With 0.82, released in October 2025, it became the only architecture: the setting to fall back to the legacy one is now ignored. That removes the main source of the "React Native feels laggy" complaints from older apps.
Flutter replaced its rendering engine. Flutter's Impeller engine compiles shaders when the app is built rather than while it runs, which was the cause of the first-run stutter people used to notice. According to Flutter's documentation, Impeller is the only supported renderer on iOS and the default on Android API 29 and later.
Kotlin Multiplatform grew up. JetBrains declared Compose Multiplatform for iOS stable in May 2025. That gives native teams a third path: share the logic, and optionally the UI, without moving to a different language or runtime.
So the old performance arguments matter much less. The decision now comes down to your team, your UI and how much you depend on the device.
Flutter: one codebase, one look
Flutter draws its own UI instead of using the platform's buttons and lists. That is both its strength and its trade-off.
Where it shines
- Pixel-identical design across iOS, Android and, if needed, web and desktop.
- Fast UI work. Hot reload and a single widget system keep design iterations short.
- Strong fit for business apps, internal tools, marketplaces and anything with a custom brand look.
Where to be careful
- Your app will not pick up platform look-and-feel changes automatically. When Apple redesigns its controls, a Flutter app keeps looking the way you designed it, for better or worse.
- Dart is a smaller hiring pool than JavaScript or Kotlin, though experienced Flutter engineers are not hard to find in India.
- Deep native features still need platform channels, which means someone on the team must be comfortable in Swift and Kotlin.
React Native: native controls, web skills
React Native renders real platform components and is written in TypeScript or JavaScript.
Where it shines
- Companies with an existing React web team can share people, patterns and sometimes code.
- The app uses the platform's own controls, so it tends to feel at home on each OS.
- Expo has made builds, updates and native modules much easier to manage than they were a few years ago.
Where to be careful
- Upgrades still take planning, especially if your app depends on older community libraries that were never updated for the New Architecture.
- Over-the-air update tooling changed: Microsoft retired its CodePush service on 31 March 2025, so older apps that relied on it need a replacement such as Expo Updates.
- Very heavy animation or graphics work can still push you toward native modules.
Native Swift and Kotlin: when the device is the product
Native costs more because you run two codebases, but some apps simply need it.
A good example from our own work is the iOS capture app we have built with Uplift Labs since 2020. It records athletes on an iPhone camera and feeds motion analysis that used to need a lab rig. Camera control, frame timing and on-device processing are the whole product, so native Swift was never in question. The same logic applied to Telehealer, a telehealth platform where the apps connect to Bluetooth medical devices and run HIPAA-grade video calls.
Native is also the safer choice when:
- You need new OS features on day one, such as the latest widgets, Live Activities or on-device AI models.
- The app does serious background work: location tracking, audio, sync.
- You already have a large native app. Rewriting it in a cross-platform framework is rarely worth it. When FundsIndia needed a better iOS app for more than a million investors, the answer was a clean Swift rewrite, not a framework change.
Kotlin Multiplatform: the middle path
Kotlin Multiplatform is worth a look if you have Android engineers and want to stop writing the same networking, validation and data code twice. Teams can share that layer and keep fully native screens, or adopt Compose Multiplatform to share screens as well. It is younger than Flutter or React Native, and the library ecosystem is smaller, but it is the least disruptive option for an existing native app.
Side-by-side comparison
| Flutter | React Native | Native (Swift + Kotlin) | Kotlin Multiplatform | |
|---|---|---|---|---|
| Language | Dart | TypeScript / JavaScript | Swift, Kotlin | Kotlin (+ Swift for iOS UI if not using Compose) |
| UI | Own rendering engine | Platform components | Platform components | Native UI or Compose Multiplatform |
| Code shared across iOS and Android | Most of the app | Most of the app | None | Logic always, UI optionally |
| Device and OS feature access | Good, via plugins | Good, via native modules | Full, immediate | Full |
| Best fit | Branded business apps | Teams with React skills | Hardware-heavy or performance-critical apps | Existing native apps |
How cost really compares
The usual claim is that cross-platform costs half as much as native. The saving is real but smaller than that. A typical mobile project includes product design, backend and APIs, QA on real devices, app store work and ongoing maintenance. Only the client-side code is shared, so on a standard business app the total saving is well short of half, because everything around the app code still has to be done once per product.
That saving shrinks when the app needs many custom native modules, and it can turn negative if you later hit a wall and rewrite. The cheapest app is the one you only build once.
Questions we ask before recommending
- What does the app do with the hardware? Camera, Bluetooth, sensors, AR and background tasks push toward native.
- Who will maintain it in three years? Match the stack to the team you can hire and keep, not just the team that builds version one.
- Do you need web or desktop too? Flutter and React Native (with React on the web) both help here.
- Is there an existing app? Extending a native app with Kotlin Multiplatform usually beats a rewrite.
- How custom is the design? A strongly branded UI suits Flutter; a "feels like iOS on iOS" brief suits React Native or native.
- What are the compliance requirements? Banking and health apps often need native security modules regardless of the main framework.
Our take
For most new business apps in 2026, a cross-platform framework is the sensible default, and the choice between Flutter and React Native should follow your team's skills and design goals. Go native when the device itself is central to the product or when you already have a strong native codebase. And whatever you choose, keep the backend and APIs clean, because that is what makes a future change of mind affordable.
If you are planning an app and want a second opinion on the stack, our mobile app development team is happy to review your feature list. Book a call and we will tell you what we would build it in, and why.
Sources
- React Native 0.82: A New Era, React Native team, October 2025: New Architecture as the only architecture, React 19.1.1, experimental Hermes V1.
- Impeller rendering engine, Flutter documentation, checked October 2026: Impeller as the only renderer on iOS and default on Android API 29+.
- Compose Multiplatform 1.8.0 released: Compose Multiplatform for iOS is stable, JetBrains, May 2025.
- JetBrains brings Compose for iOS to stable, Neowin, May 2025.
- Flutter vs React Native in 2026: a technical architecture comparison, Shorebird, February 2026: rendering models, JSI, and the retirement of Microsoft CodePush on 31 March 2025. Shorebird sells Flutter update tooling.