- Cross-platform saves 30–40% of build cost on our projects, not the 50% usually claimed.
- Permissions, push, in-app purchases, deep linking and final polish do not share between platforms; budget for them separately.
- Flutter suits design-led apps and fresh teams; React Native suits teams already running React on the web.
- Hardware-dependent apps, strict background execution and regulated platform security are the cases where native still wins.
- One codebase pays back most in the maintenance year, and the cost of that choice is a quarterly upgrade tax.
We build in both Flutter and React Native, and occasionally native, so we have no side in this argument. What follows is the decision framework we walk clients through, and the honest cost picture behind it.
The five questions
Does the app depend on hardware or background behaviour? Continuous location tracking, Bluetooth peripherals, camera processing beyond taking a photograph, audio processing, tight battery constraints. If yes, native is usually the right call, or a hybrid with native modules for those parts.
Do you need platform features the week they ship? If being first on a new OS capability is part of your positioning, native. Cross-platform frameworks lag by months on new APIs.
Is the interface conventional? Lists, forms, dashboards, media, chat: cross-platform handles all of these well. Highly custom gesture-driven interfaces and complex animation are where it stops saving time.
What does your team already know? A team with React experience will be productive in React Native in weeks. A team with no JavaScript background often prefers Flutter and its more prescriptive structure. This matters more than either framework's technical merits.
How long will you maintain it? Over three to five years, one codebase means one queue of bugs, one release process and one place to add a feature. This is where cross-platform pays back most, and it gets the least attention in the decision.
What cross-platform actually saves
The claim you will see is 50%. Our estimates from real projects put it closer to 30–40% of total build cost.
The saving is concentrated in shared business logic, state management, API integration and most screens. What does not share: platform-specific permissions and their handling, push notifications, in-app purchases, deep linking, store submission, and the last 10% of polish that makes an app feel native on each platform.
That last item is where teams new to cross-platform lose their savings. Budget for it explicitly rather than discovering it in the final sprint.
Flutter in 2026
Flutter renders its own widgets, so the interface is identical everywhere and independent of platform updates. In practice: excellent visual consistency, strong animation performance, and a hot reload workflow developers like.
The trade-offs. Dart is a smaller talent pool than JavaScript in most cities, including ours. App sizes start larger. And because it draws its own controls, an app that should feel platform-native takes deliberate work to get there.
Good fit for design-led apps with a brand of their own, teams starting fresh, and products where both platforms must look identical.
React Native in 2026
React Native uses actual platform components, so an app tends to feel right on each platform with less effort. The newer architecture has closed most of the historical performance gap. If you already run a React web codebase, sharing logic, types and developers between web and mobile is a real advantage rather than a theoretical one.
The trade-offs: a larger dependency surface, upgrades that need care, and an ecosystem that moves fast enough for unmaintained libraries to be a genuine risk. Pin versions and audit dependencies before adopting them.
Good fit for teams with React experience, products with a web application alongside the app, and apps that should feel conventional on each platform.
When to go native anyway
We recommend native without much hesitation for apps where hardware is the product, anything with strict background execution requirements, apps where a regulator or an enterprise customer requires platform-specific security features, and single-platform products where the second platform is genuinely not planned.
Also when the app is small, simple and only one platform matters. Two native codebases of 4,000 lines each is not a crisis.
The hybrid position
Most of the interesting builds we do now are hybrid in the honest sense: cross-platform for the bulk of the application, native modules for the two or three things that need them. Both frameworks support this well and it is usually cheaper than either purist position.
The planning requirement is to identify those modules before starting, not when a sprint hits a wall.
We build cross-platform apps in Flutter and React Native, and native modules where they are genuinely needed, with the platform work scoped up front.
What the maintenance year looks like
The build is the part everyone plans for. The twelve months afterwards decide whether the choice was right.
In a single codebase a bug is fixed once and released twice. In two native codebases it is triaged twice, fixed twice, reviewed twice, and can be fixed differently in each. Over a year of ordinary maintenance on a mid-sized app, that difference is usually worth more than the original build saving.
Against that, cross-platform adds an upgrade tax. Both frameworks release regularly and dependencies age faster than native SDKs. Budget a few days per quarter for keeping current, and treat an app left on a two-year-old framework version as technical debt with a due date attached. The projects that hurt are the ones where nobody opened the repository for eighteen months and the upgrade path now runs through four breaking releases.
What we tell clients to ignore
Benchmark comparisons of frame rates, which measure things nobody perceives in a business app. Claims that one framework is dying, made about both continuously for six years. And the idea that cross-platform apps get rejected by the app stores, which has not been true for a very long time.
The decision in one sentence
If your app is mostly screens, forms and data, choose the cross-platform framework your team can staff, and budget an extra 15% for platform-specific work. If it is mostly hardware, background processing or platform-native behaviour, build native and stop reading comparison articles.
Either way, decide before the first sprint who will still be maintaining this in year three. If the answer is an in-house team, that team's language wins the argument on its own; if the answer is us, we will say so at the estimate stage. Our cross-platform and native app pages set out how each is scoped, and the launch side is covered in getting the first 1,000 real installs.
Questions
Is Flutter better than React Native?
Neither is better in general. Flutter gives more visual control and consistency; React Native gives a more native feel and shares talent with web teams. The team you can hire and the codebase you already have usually decide it.
How much cheaper is a cross-platform app?
In our projects, 30–40% less than two native builds, not the 50% often quoted. Shared logic saves a lot; platform integration, store work and final polish save little.
Will a cross-platform app feel slow?
Not for typical business apps on current hardware. Perceptible differences show up in heavy animation, real-time media and continuous background work, which is exactly where we recommend native.
Can I convert an existing native app to cross-platform?
You can, but treat it as a rewrite rather than a conversion. The realistic path is usually to build new features cross-platform in a hybrid setup and migrate screens gradually.
What about a progressive web app instead?
Worth considering when there is no need for store distribution, hardware access or push on every platform. It is cheaper and it updates instantly. Discovery, offline behaviour and platform integration are all weaker.