Ask ten mobile developers which framework to use and you will get ten confident answers, most of which describe the last app that developer built rather than yours. The question is answerable, but only after you know four things about what you are building.
The four questions that decide it
1. How much of your app touches the platform directly?
Camera pipelines, Bluetooth peripherals, background location, audio processing, widgets, watch apps, health data, on-device machine learning, CarPlay or Android Auto. Every one of these has a native API, and every cross-platform framework reaches it through a bridge that someone has to maintain.
One or two of these is fine — you write a platform channel and move on. Five of them and you are writing a native app in two places plus a framework in the middle, which is the worst of every option.
2. Should the two platforms behave identically, or natively?
A banking app generally wants identical behaviour: same flows, same rules, same screens, audited once. A consumer social app usually wants to feel native on each platform, which means different navigation patterns, different share sheets, different gestures.
Cross-platform frameworks are excellent at the first and workable at the second. If “it should feel like a proper iOS app” is a stated requirement rather than a nice-to-have, weight that heavily.
3. Who maintains this in two years?
The most expensive framework is the one you cannot hire for. Consider what your team looks like after launch: an in-house developer, an agency, nobody yet? A Flutter codebase maintained by a team that only knows Swift is a liability regardless of how good the code is.
4. What is the real budget, including year two?
Two native apps cost roughly 1.6–1.9× a single cross-platform app for equivalent scope — not 2×, because design, backend, product and QA are largely shared. That multiplier applies again to every feature you add afterwards, and to every OS upgrade cycle.
What each option is actually good at
Native (Swift + Kotlin)
The ceiling is highest and there is no bridge between you and the platform. New OS features are available the day they ship rather than whenever a plugin catches up. Performance-critical work — camera, audio, graphics, heavy background processing — has no better home.
The cost is duplication. Two codebases, two test suites, two release trains, and either two developers or one developer doing twice the work and context-switching between two languages.
Choose it when: the app is hardware-heavy, platform conventions matter commercially, you already have native engineers, or the app is your entire product rather than a channel to it.
Flutter
One codebase, one language, and Flutter renders its own UI rather than wrapping platform widgets. That gives you genuinely consistent output across platforms and excellent control over animation and custom design. Tooling is mature and hot-reload materially speeds up UI iteration.
The trade is that because Flutter draws its own widgets, matching a platform’s native feel precisely takes deliberate effort, and Dart is a smaller hiring pool than JavaScript or the native languages. Anything deeply platform-specific still needs a channel to native code.
Choose it when: design is custom and brand-led rather than platform-led, the two platforms should match, and you want one team shipping both.
React Native
One codebase, JavaScript or TypeScript, and it renders real native components. The enormous advantage is organisational: if you have a web team, they are already most of the way there, and code and people can move between web and mobile. The library ecosystem is the largest of the three.
The trade is dependency management. Much of the ecosystem is community-maintained, and upgrades across React Native versions can be genuinely disruptive if your dependency list is long and old.
Choose it when: you have a React web codebase or team, you want native components rather than a custom renderer, or you expect to share logic between web and mobile.
A rough decision table
| If this is true | Lean toward |
|---|---|
| Five or more deep platform integrations | Native |
| Performance is the product (camera, audio, games) | Native |
| Platform-native feel is a commercial requirement | Native |
| Custom, brand-led design across both platforms | Flutter |
| Identical behaviour required on both platforms | Flutter |
| Existing React web team or codebase | React Native |
| Sharing business logic with a web app | React Native |
| Small budget, broad but shallow feature set | Flutter or React Native |
| No idea who maintains it in year two | Whatever you can hire for locally |
What people get wrong
Choosing on benchmarks. Every framework is fast enough for a list, a form and a checkout. Unless you are rendering complex real-time graphics, framework performance will not be what your users complain about. Image loading, network waterfalls and unbatched database queries will.
Treating it as permanent. It is not all or nothing. Plenty of production apps are cross-platform with two or three native modules for the parts that need them. That is a normal, healthy architecture.
Ignoring the second-year cost. The framework decision is mostly a decision about maintenance, and maintenance is where most of the money goes. Ask what upgrading costs, not just what building costs.
Letting the developer decide alone. This is a business decision with technical inputs. The person making it should understand your hiring plans and your budget, not only your architecture.
How we answer it
We decide during discovery, in writing, with the reasoning attached. It takes a list of every platform capability the app needs, an honest look at who maintains the code afterwards, and a cost comparison across two years rather than one build.
Roughly two thirds of the apps we scope come out cross-platform. The third that do not are almost always hardware-heavy, and the difference is obvious once the integration list exists.
If you want a second opinion on a decision you have already made, we will give you one for free. Send us the feature list — we will tell you whether the choice holds up.