Native vs Cross-Platform App Development: How to Choose

Ten years ago this was a real debate. Today cross-platform is the right default for most business apps, and the interesting question is which exceptions still justify native.

The options, plainly

Native means an iOS app written in Swift and an Android app written in Kotlin: two codebases, two teams or one team doing everything twice. Cross-platform means one codebase - in Flutter or React Native - that produces both apps. Both approaches ship to the same stores and look, to users, like apps.

Why cross-platform is the default

• Cost. One codebase is 30 to 40 percent cheaper to build and roughly half the cost to maintain, because every change is made once.
• Consistency. Both platforms get the same features on the same day. With two native apps, one is always behind.
• Maturity. Flutter and React Native are used for apps with tens of millions of users. The old objections about performance and platform feel are mostly historical.
• Team. One team, one skill set, one set of tools. For a business that will have one developer maintaining the app in year three, this matters more than anything technical.

For the field-service tools, customer apps, booking apps and internal apps that make up most of our app development work, cross-platform is what we recommend and build.

Where native still wins

Hardware-heavy apps

Continuous camera processing, Bluetooth peripherals with demanding protocols, background location at high accuracy, augmented reality. Cross-platform frameworks reach these through plugins, and when the plugin does not do exactly what you need, you are writing native code anyway.

Platform-first products

Apps whose whole point is deep integration with one platform: widgets, watch apps, CarPlay, Siri shortcuts, the latest OS feature on launch day. If you are only shipping to one platform, native has no cost penalty and full access.

Performance at the edge

Games, heavy animation, large lists of rich media, real-time audio and video. Cross-platform can do most of this well now, but if performance is the product, native removes a layer.

Very large teams

At the scale where you have separate iOS and Android teams anyway, native lets each move independently. This does not describe most UK SMEs.

Flutter or React Native?

Both are good. Flutter draws its own interface and is very consistent across platforms; React Native uses the platform's native components and suits teams that already know React. The choice matters less than the team's fluency in it. Ask an agency which they use and why, and check that the answer is about your project rather than their preference. We use both and pick per project.

The web app alternative

Before choosing between app approaches, check whether you need an app. A progressive web app - a website built to feel like an app, installable to the home screen, with limited offline support and notifications on Android - covers a surprising share of "we need an app" requests at a fraction of the cost, with no store review. It fails when you need real offline capability, deep hardware access, or the iOS notification and install experience. Our app cost guide covers where the line sits.

The question that settles most cases

Which device features does the app depend on, and does any of them need to work at the edge of what the device can do? If the answer is "camera for photos, GPS for location, push for reminders" - cross-platform, without hesitation. If the answer includes "continuously", "real-time" or "in the background at high precision", talk about native for that piece.

What the choice costs later

What "platform feel" really means now

The historic objection to cross-platform was that apps felt slightly foreign on each platform: wrong navigation gestures, non-standard controls, a half-second of jank. Flutter and React Native have both closed most of that gap, and the remaining differences are ones most business users never notice. Where it still matters is in consumer apps competing on polish against native rivals, and in apps whose users are the kind of people who notice. For a field-service tool or a customer portal, it does not.

Maintenance in year two, compared

Every autumn brings a new iOS and a new Android. Each breaks something: a permission model changes, a deprecated API stops working, a store rule tightens. With two native apps, that is two investigations, two fixes, two submissions. With cross-platform, it is usually one fix in shared code plus platform-specific adjustments where needed. Over a five-year life, this is where the cost gap widens from 30 to 40 percent at build to closer to half on maintenance. The app cost guide puts numbers on the year-two bill.

Mixed approaches

You can build cross-platform and drop to native for one component that needs it - a camera pipeline, a Bluetooth driver - without rewriting the app. Good agencies do this routinely. It is the answer when 95 percent of the app is ordinary and 5 percent is demanding, which describes a lot of real products.

How we decide

List the device features the app depends on. Mark each as "occasional" (take a photo, get a location) or "continuous" (process the camera feed, track location in the background all day). List the platforms and whether they must reach parity. Count the interactive screens. If everything is occasional and both platforms matter, cross-platform. If something is continuous, native for that piece, cross-platform for the rest. If one platform only, native has no penalty. We put that reasoning in writing for every app we quote.

A short checklist for the conversation with your agency

• List every device feature the app uses, marked occasional or continuous.
• Confirm which platforms must launch together.
• Ask which framework they propose and why for this app, not in general.
• Ask how OS updates will be handled each year and what that costs.
• Ask what happens if one screen turns out to need native code.
• Confirm the app will be published under your developer accounts.

An agency that answers these in plain terms has made the decision on the merits. One that only builds one way will recommend that way regardless of the answers.

Whichever way you go, insist on the same three things: the code in a repository you control, the app published under your own developer accounts, and a written maintenance plan for the annual OS updates. Those matter more to the app's life than the framework underneath it.

Two native apps mean two maintenance streams, two sets of OS-update breakages a year, and two skill sets to hire. For an app that will live five years, that is often the deciding factor. If you are not sure, describe what the app has to do and we will tell you which approach we would use and why.