Before a startup picks between Flutter and React Native, there is an earlier question that often gets skipped: should the app be cross-platform at all, or should it be built natively, in Swift for iOS and Kotlin for Android? It is a decision about the product as much as the code, because it sets what you can ship, how fast, and with how many people.
We have already compared the two main cross-platform options in Flutter vs React Native for a startup MVP, so this post does not repeat that. Here we put Flutter against native development and look at where each one honestly wins.
What you are actually choosing between
Native means two apps: one written in Swift, usually with SwiftUI or UIKit, and one in Kotlin, usually with Jetpack Compose. Each uses its platform's own controls, tools and SDKs directly. You get everything the platform offers, and you build and test every feature twice.
Flutter means one app written in Dart. It compiles to machine code and draws every pixel through its own rendering engine, Impeller, which is now the default on iOS and on modern Android devices. Flutter recreates platform behaviour such as scrolling physics, page transitions and text selection, and ships Material and Cupertino widget sets, but the controls are Flutter's own drawings rather than the system's. When it needs a platform API, it calls into Swift or Kotlin through platform channels or generated bindings.
Should a startup build its app in Flutter or native?
A startup should usually build in Flutter when it needs to ship on iOS and Android with a small team, and build native when the product's value depends on what each platform does uniquely. Flutter gives you one Dart codebase that compiles to machine code and draws its own interface, so a custom, brand-led design looks the same on both platforms and every feature ships to both stores together. That is a strong fit for most marketplaces, booking, fintech, insurance and content apps. Native Swift and Kotlin win when the app leans on deep hardware or background work, heavy 3D or AR graphics, a single platform, new operating system features on the day they launch, or controls that must match the system exactly. Many teams land in between: Flutter for the shared app, with thin native modules for the few features that need them. Check every must-have platform API before you decide, not after.
When one Flutter codebase wins
- You need both app stores soon. One codebase means every feature, fix and experiment lands on iOS and Android together instead of one platform trailing the other.
- Your team is small. A handful of engineers can own the whole app without splitting into separate iOS and Android groups that drift apart.
- The design is custom and brand-led. Because Flutter draws its own interface, a bespoke design looks the same on both platforms with less platform-specific tuning.
- You are still learning what the product is. Stateful hot reload and a single place to change behaviour make fast iteration cheaper while the roadmap keeps moving.
- You want the same code on more surfaces later. Flutter also targets web, desktop and embedded devices, which suits internal tools and companion apps, though it is a weaker fit for content-heavy public websites.
Most startup apps sit here: marketplaces, booking, fintech, insurance, health portals, learning and content apps. Their value is in the product flows and the backend, not in squeezing the last detail out of each platform. Our Oneplan insurance app is a typical case: one Flutter codebase for iOS and Android handling claim cards, benefits and document uploads against the insurer's existing systems.
When native wins
Deep hardware and background work
If the core of the product is Bluetooth devices, continuous location, background audio, health sensors, NFC, or long-running background tasks, you will spend much of your time in platform APIs anyway. Flutter plugins wrap many of these, but plugin quality varies, and when one falls short you are writing Swift and Kotlin plus the bridge between them. At that point a native app can be the simpler system.
Heavy graphics, AR and real-time media
Flutter handles rich 2D interfaces and animation well. Apps built around 3D scenes, augmented reality or real-time camera and video pipelines tend to depend on platform frameworks for graphics, AR and media. You can embed native views inside Flutter, but its own docs describe trade-offs: depending on the mode, embedded views can cost frame rate or cause jank during fast scrolling. When those views are the whole product, native is usually cleaner.
Apps for one platform
Cross-platform pays off when there is a second platform. An iPad-first tool for a specific profession, an Android app for managed company devices, or a product whose users are overwhelmingly on one platform gains little from Flutter and gives up direct access to that platform's tools and talent pool.
New OS features on day one
Native apps get new platform features as soon as Apple or Google ship them. Cross-platform frameworks have to catch up. Apple's Liquid Glass design is a recent example: the Flutter team said in 2025 that it would not build those features into its Cupertino library at first, and moved that work into separate packages, where official widgets were still in progress in October 2026. Some features also need native code regardless of framework. iOS app extensions, such as share sheets, are native targets that can host Flutter, and home screen widgets are built with Apple's own frameworks.
Platform UI fidelity
If your users expect an app that looks and behaves exactly like the system, with native text fields, menus, accessibility behaviour and the latest system styling, native gives you that by default. Flutter gets close, and its adaptive widgets switch to Cupertino styling on iOS, but close is not identical, and the gap is easiest to notice in utility and productivity apps where users live in the system controls all day.
The middle ground most teams end up in
The choice is rarely pure. A Flutter app can call platform code through platform channels, and the Pigeon package generates type-safe bindings so the Dart and native sides stay in step. Most production Flutter apps of any size carry a thin layer of Swift and Kotlin for the features that need it. Going the other way, Flutter's add-to-app support lets an existing native app embed Flutter screens, which is useful for sharing one complex flow across both platforms without a rewrite.
There is also a third option worth knowing: Kotlin Multiplatform shares business logic such as networking, storage and validation across iOS and Android while keeping each interface fully native. It suits teams that want native UI but do not want to write the logic twice.
A quick decision checklist
- List the five features your product cannot launch without, and check which platform APIs each one needs.
- For each API, confirm that a maintained Flutter plugin exists, or estimate the native code you would write yourself.
- Decide whether you need both stores at launch, or whether one platform comes first.
- Ask whether your design is custom and brand-led, or whether users expect standard system controls.
- Check whether any feature depends on graphics, AR, media or background work that sits at the heart of the product.
- Look at your team: who you have now, who you can hire next, and who will maintain the app later.
- If most answers favour shared code and few features are platform-heavy, choose Flutter with native modules. If the platform-heavy features are the product, choose native.
Where SI features change the picture
Adding SI features rarely decides this on its own, because most of them run on a server and are called over an API from either kind of app. On-device models are different. Apple's Foundation Models framework, for instance, is a Swift API, so a Flutter app reaches it through a plugin or its own platform channel, and Android's ML Kit GenAI APIs for Gemini Nano are native Android SDKs. That is a thin native layer, not a reason to go fully native. Our guides to adding SI features to a mobile app and on-device vs cloud LLMs in Flutter cover the trade-offs in more depth.
Getting a second opinion
For most startups, Flutter with a small native layer is the faster, simpler way to reach both stores. For the products where the platform is the point, native earns its extra cost. If you want a second pair of eyes on your must-have feature list before you commit, Octalcode's custom software and mobile team builds in both Flutter and native code, and we will tell you which one your product actually needs.