The native versus cross-platform debate is usually argued on performance, which is the wrong axis. What decides it is how much of your app is genuinely platform-specific.
The native versus cross-platform debate is usually argued on performance, which is the wrong axis for most projects. Cross-platform performance stopped being the deciding factor some time ago. What decides it now is how much of your app is genuinely platform-specific, and who is going to maintain it in three years.
Here is how the options actually differ, and which questions produce a defensible answer.
The current landscape
Before comparing, it is worth being clear about what is actually available, because the list has changed and stale advice is common.
- Native — Swift with SwiftUI for iOS, Kotlin with Jetpack Compose for Android. Two codebases, full access to everything each platform offers.
- React Native — JavaScript or TypeScript, rendering real native components. Strong fit where you already have React expertise in the business.
- Flutter — Dart, with its own rendering engine that draws the interface rather than using platform widgets. Consistent across platforms by design.
- .NET MAUI — C# and .NET. This is the successor to Xamarin, which reached end of support on 1 May 2024. If you are reading a guide that still recommends Xamarin for new work, it predates that change.
- Kotlin Multiplatform — shares business logic across platforms while leaving the interface native to each. A middle path that suits apps where the logic is complex and the interface should feel genuinely native.
- Progressive web app — a website with offline capability and an install prompt. No app store, no install friction, real limitations on device access.
The question that actually decides it
Estimate what proportion of your app is interface and business logic that could be identical on both platforms, versus deep platform integration that cannot.
Content, forms, lists, dashboards, messaging, booking, e-commerce — these are largely the same work twice if you build natively. A cross-platform framework removes that duplication and the ongoing cost of keeping two implementations in step.
Sustained background location, complex camera control, tight integration with platform health or payment ecosystems, heavy on-device processing, widgets and deep system extensions — these are where cross-platform frameworks require native modules anyway. If a large share of your app is this kind of work, you end up maintaining a cross-platform layer *and* platform-specific code, which is the worst of both.
A rough rule that holds up in practice: if more than about a fifth of the app is genuinely platform-specific, the cross-platform saving erodes quickly.
Cost, honestly
The common claim is that cross-platform halves the cost. It does not, for two reasons.
First, a meaningful share of any app project is not platform-specific development at all: design, backend work, testing, app store submission, and project management. Sharing the client code does not halve those.
Second, testing does not halve. You still test on both platforms, on a spread of devices and OS versions, because rendering differences and platform behaviours still produce platform-specific bugs.
The saving is real but sits closer to a meaningful reduction than a halving — and it is larger in maintenance than in the initial build, because every subsequent feature is written once rather than twice.
Where each option is the right answer
Choose native when
The app depends on platform capabilities that arrive first on native, performance in graphics or sustained processing is central to the product, you are building for one platform only, or you have existing native teams. Building for one platform natively is frequently the correct choice for a first release, and it is often cheaper than a cross-platform build serving an audience you have not validated.
Choose React Native when
Your organisation already writes React, you want to share knowledge and possibly code with a web product, and the app is largely interface over an API. The practical advantage is hiring and internal mobility: React developers are widely available.
Choose Flutter when
You want a consistent, strongly branded interface across platforms and are content for it not to precisely match each platform's conventions. Because it draws its own widgets, it gives you control over appearance and predictable rendering — an advantage for design-led products and a mild disadvantage where users expect native behaviour. Getting that interface right is design work before it is development work, and our design team handles it alongside the build.
Choose .NET MAUI when
You are a .NET organisation with existing C# skills and backend services, particularly for internal or line-of-business applications where reusing domain code matters more than a distinctive interface.
Choose a progressive web app when
Your app is essentially a website with occasional offline use, discovery matters more than device integration, and you want to avoid app store review cycles. Be clear about the limits before committing: device capability access is narrower and varies by platform.
The costs that appear after launch
Budgeting a mobile app as a project rather than a commitment is the most common planning error. Ongoing obligations include annual developer programme fees, mandatory updates when platforms raise minimum requirements or deprecate APIs, backend hosting, and the practical reality that an app which is not updated for a year looks abandoned to users.
Cross-platform frameworks add a specific ongoing cost: framework upgrades. Major versions require migration work, and third-party packages sometimes lag behind. Native platforms have their own churn, but you are dependent on one fewer layer.
Before you build an app at all
The question worth asking first is whether the app is the right vehicle. Installation is a real barrier, and an app is justified when people use it repeatedly, when you need capabilities the web cannot reach, or when offline operation is essential.
If your users would visit a few times a year, a responsive website will usually reach more of them at lower cost. Businesses regularly build an app because competitors have one, then discover that acquiring installs is a larger and more expensive problem than building the software. We cover the web-side alternative in our post on custom websites.
Frequently asked questions
Is cross-platform noticeably slower?
For typical business apps — lists, forms, content, network requests — no, not in a way users perceive. The gap appears in sustained heavy processing, complex animation and graphics-intensive work. If your app is one of those, it is a real consideration; if it is a booking or catalogue app, it is not.
Can we start cross-platform and move to native later?
You can, but it is effectively a rebuild of the client, so treat it as a decision rather than a fallback. What transfers is your backend, your design work and your understanding of what users need — which is not nothing, but the app itself is rewritten.
Should we launch on both platforms at once?
Not necessarily. Launching on one platform first lets you learn from real users before doubling the surface area you maintain. Choose based on where your actual customers are rather than general market share.
What about Xamarin — we already have an app built on it?
Support ended on 1 May 2024, so an existing Xamarin app is no longer receiving updates and will eventually be blocked by store requirements. Microsoft's path is migration to .NET MAUI for Xamarin.Forms apps, or to .NET for Android and iOS for the platform-specific SDKs. If you have a Xamarin app in production, planning that migration is now a maintenance obligation rather than an optional improvement.
How long does an app take to build?
Most schedules are set by the backend and by decision-making rather than the app itself. Apps with a clear specification and an existing API move fastest. Apps where requirements are still being discussed during development take as long as the discussion does. If the API does not exist yet, that backend work sits with our infrastructure team and should be scheduled before the app build rather than alongside it.
How to decide
Estimate the proportion of your app that is genuinely platform-specific. If it is small, cross-platform will serve you well and the choice between frameworks should follow your team's existing skills. If it is large, build natively and accept the cost. And before either, confirm that an app is the right answer rather than a better website.
Our development team works across these options and will tell you which fits your requirements — including when the honest answer is that you do not need an app. Get in touch to talk through what you are building.
