Native vs Flutter vs React Native for a UK startup

If you are commissioning an app, one of the first technical decisions is how it will be built. There are three realistic options for most startups in 2026: native apps (Swift for iPhone, Kotlin for Android), Flutter, or React Native.

You will find strong opinions online about each one. Most of them come from developers who use only one. We build in all three at Tyche Labs, so this is our attempt at a fair comparison and a simple way to decide.

The three options in plain English

Native

A native app is written in the language and toolkit each platform's maker recommends. On Apple devices that means Swift and, for the interface, SwiftUI, which Apple describes as a way to build apps "across all Apple platforms with the power of Swift" ^[1][2]. On Android it means Kotlin; Google announced in 2019 that Android development would be increasingly Kotlin-first ^[3], and it calls Jetpack Compose its "recommended modern toolkit for building native UI" ^[4].

If you want both platforms natively, you build two separate apps with two codebases.

Flutter

Flutter is Google's open-source framework for building apps for mobile, web and desktop "from a single codebase" ^[5]. You write in a language called Dart, which compiles ahead of time to machine code for mobile apps ^[7]. Flutter draws its own interface rather than using the platform's standard controls. Its rendering engine, Impeller, has been the default on iOS and on Android API 29 and above since the 3.27 release, and it precompiles its shaders so they don't compile while the app is running ^[6]. In practice that means smooth, consistent animation and an app that looks the same on both platforms.

React Native

React Native lets you write the app in JavaScript or TypeScript using React. Its tagline is "Written in JavaScript, rendered with native code": your components map to the platform's real interface elements ^[9]. Version 0.76 made the "New Architecture" the default in October 2024 ^[10], and version 0.82 in October 2025 was the first to run entirely on it ^[11]. The React Native docs recommend using a framework for new apps, such as Expo, which provides "file-based routing, high-quality universal libraries, and the ability to write plugins that modify native code without having to manage native files" ^[12].

When native wins

Choose native when one or more of these is true:

• You are launching on iPhone first. Many UK consumer and B2B products can validate on one platform. One native app is often the fastest, simplest route to a first release.
• The app lives close to the hardware. Camera pipelines, audio processing, on-device machine learning, Bluetooth accessories, background location, widgets and other system integrations are easiest with direct access to the platform's own APIs.
• You need new platform features on day one. When Apple or Google release a new capability, it appears in Swift and Kotlin first. Cross-platform frameworks get there, but sometimes later and sometimes through a plugin someone else maintains.
• Performance is the product. Video, real-time audio and heavy graphics leave the least margin for overhead.

A real example: our own app Cuefold, a teleprompter camera, records video while running on-device speech recognition and selling subscriptions through StoreKit 2. Almost every important part of it talks directly to Apple frameworks, so we built it in native Swift 6 and SwiftUI. A cross-platform layer would have added little and got in the way.

The trade-off is cost when you need both platforms. Two native apps means two codebases to build, test and maintain.

When Flutter wins

Choose Flutter when:

• You need iOS and Android from launch and most of the app is standard product screens: lists, forms, dashboards, booking flows, content.
• You want a strongly branded interface that looks identical on both platforms. Because Flutter draws every pixel itself, custom designs are easy to reproduce exactly.
• You don't already have a JavaScript team. Dart is quick to learn, and a single small team can own the whole app.
• You might add web or desktop later. Flutter targets these from the same codebase ^[5], although a mobile-first Flutter app usually needs design work to feel right on a large screen.

Where Flutter needs care: if the app must look and behave exactly like a standard iPhone app, matching every platform detail takes effort. And anything Flutter doesn't cover out of the box needs native code connected through platform channels ^[8], which means someone on the team still needs Swift and Kotlin skills.

When React Native wins

Choose React Native when:

• You already have a React web app or team. Developers who know React can be productive quickly, and some business logic, types and validation can be shared with a web product.
• You want the platform's own interface elements rather than a custom-drawn look ^[9].
• You value the JavaScript ecosystem and Expo's developer tooling ^[12].

Where React Native needs care: like Flutter, it depends on third-party libraries for many device features, and the quality of those libraries varies. Upgrades across major versions have historically taken real work, though the move to the New Architecture ^[10][11] was meant to put that on a firmer footing.

Cost: what we charge

These are Tyche Labs' typical ranges, not market statistics:

A cross-platform app is often less than building two native apps, depending on how much platform-specific work there is. If half of your app is camera, audio or hardware integration, the savings shrink, because that half gets written per platform anyway. If it is mostly standard screens talking to a server, the savings can be substantial.

The other comparison that matters is one native app versus one cross-platform app. If you only need iPhone at launch, a native app is often the cheaper choice, because there is no framework layer to work around.

Myths worth ignoring

"Cross-platform apps are slow." For typical business apps, a well-built Flutter or React Native app is fast enough that users won't notice. Performance problems usually come from how an app is built, not which framework it uses.

"Native is always better." Native is better at some things. It is not automatically better value for a product that needs two platforms and has no special hardware needs.

"The framework decides whether Apple approves you." App Review judges the app, not the language. Rejections come from crashes, missing information, privacy problems and metadata issues, whatever the app is written in. See our guide to App Store rejections.

"We can switch later easily." You can, but it is a rewrite. Choose with your next two years in mind, not just the first release.

A simple decision framework

Answer these in order:

1. Do you need Android at launch? If not, and your users are on iPhone, start native on iOS. Add Android when you have evidence it is worth it.
2. Is the core of the app hardware, media or deep OS integration? If yes, lean native, even for two platforms.
3. Do you already have React developers or a React web app? If yes, React Native is usually the natural fit.
4. Do you want a custom, brand-led interface identical on both platforms? If yes, Flutter is usually the natural fit.
5. Still undecided? Either cross-platform option will serve a standard business app well. Pick the one your long-term team, in-house or agency, is strongest in. Who maintains the app in year two matters more than small technical differences.

Whichever route you take, make sure you own the source code and the store accounts, and that the code is in a repository you control. That keeps your options open whatever you choose.