Native vs. cross-platform: which is right for you?

Native app or cross-platform — that's the first big fork in the road once you decide to have an app built. It shapes your budget, your speed, your maintenance, and how good your app ends up feeling. The honest short answer: there's no universally right choice, only the one that fits what you're building. Let's look at when each makes sense.

Native vs. cross-platform: what is best for me? Five questions

Short answer: Cross-platform (React Native or Flutter, for example) is right for the vast majority of business apps — anywhere you want to serve iOS and Android on one budget and the app is mostly content, forms and standard features. Native (SwiftUI for iOS, Kotlin for Android) is right when only one platform really counts, or when your app sits deep inside the operating system.

Which description fits you takes about two minutes to work out. Five questions:

1. Do you actually need both platforms? If your audience is effectively all on iOS, or you're building an internal app for company iPhones, cross-platform's biggest advantage disappears — native is the cleaner choice then.
2. What does the app do at its core? Lists, forms, bookings, a customer portal: cross-platform. Elaborate animations, camera or sensors running continuously, games: native.
3. How deep in the system does your most important feature sit? Widgets, live activities, the lock screen, background transfers, system search, the share sheet, the Files app — the more of those you need, the more native makes sense.
4. How fast do you need to be live? If you have a market window or you're testing an idea as an MVP, one codebase across two stores is the faster route.
5. Who maintains the app three years from now, and with what? Two native codebases mean two maintenance agreements, two rounds of testing, two release cycles. This is the line item that flips the decision most often.

If three or more of your answers point toward "both platforms, standard features, live fast", you can stop reading: cross-platform. For everything else, the details are worth it — and that's what comes next.

What native means, what cross-platform means

Native development means: you build the app specifically for one operating system, using its own tools. For iOS that's usually SwiftUI today (Apple's modern UI framework), for Android Kotlin with Jetpack Compose. If you want both platforms native, you're essentially building two apps — with two codebases.

Cross-platform means: you write the code once and run it on both iOS and Android. The most common approaches are React Native (JavaScript/TypeScript-based, closely related to the web world) and Flutter (Google's framework built on the Dart language). One codebase, two stores.

Worth knowing: cross-platform doesn't mean "web app in a wrapper". Modern frameworks produce real app interfaces built from native components. The gap to native is much smaller today than it was a few years ago.

Cost: the most obvious lever

This is where the difference is most tangible. Native iOS plus Android means two separate builds — roughly speaking, you pay for a lot of things twice: two codebases, often two specialists, two rounds of testing. Cross-platform shares most of the code and saves noticeably as a result.

Run it against our own price list and you don't need a percentage rule of thumb: an app MVP starts at €7,900. If the same app should run on both platforms, add €3,900 — €11,800 together. Two separately built native apps mean paying the full effort twice. So the gap is roughly a quarter to a third, and it grows with every follow-up release: one codebase is maintained instead of two, and support runs once from €149/month instead of twice.

One important caveat: if you only need one platform anyway — a pure iOS app for an Apple-heavy audience, say — that cost advantage disappears. Native is often the cleaner choice then, because you skip the framework's abstraction layer.

You'll find what our packages cost and what goes into them on our pricing page — this article stays with the fundamental tech decision.

Performance: does it even matter for you?

Native apps are theoretically ahead: they talk to the operating system directly, with no layer in between. For very graphics-heavy apps, smooth 60/120 fps animations, demanding real-time processing or games, that lead is real and noticeable.

But for most business apps: the performance difference is barely perceptible in everyday use. A booking app, a customer portal, an ordering or service tool feels just as smooth with React Native or Flutter as it does native. Here you'd be paying a premium for native performance your users will never notice.

So the honest question isn't "which one is faster?" but "will my users notice the difference?". For classic business apps: usually not.

Access to device features

Camera, GPS, push notifications, Bluetooth, Face ID, NFC — most standard device features have long been well covered in cross-platform frameworks, through ready-made modules or plugins.

Native has the edge as soon as you need brand-new or very specialized capabilities:

• A new iOS feature Apple just announced is available in native immediately — in a cross-platform framework, sometimes only weeks later.
• Deep, unusual hardware integration (exotic sensors or specialized peripherals, for instance).
• Complex background processing that hangs closely off the operating system.

The good middle ground: even in a cross-platform app, individual critical spots can be extended with native code. So you don't have to commit 100 percent.

Why we built our own app natively — and when we wouldn't

The most honest answer to "what is right for me?" isn't a table. It's a decision someone made and paid for themselves. Our own iOS app, WebDAV Browser, is built entirely in native SwiftUI. The reason is right there in its feature list, which reads like a list of system integrations:

• Indexing progress runs as a live activity on the lock screen and in the Dynamic Island, complete with an ETA.
• Uploads keep running in the background even when the app is closed — that's operating-system territory, not a UI concern.
• Text recognition runs on the device, and the results show up in the iPhone's Spotlight search afterwards.
• Passwords live only in the iCloud Keychain; connections sync between iPhone and iPad via CloudKit.
• Plus a share extension, a document scanner, the QuickLook viewer, iPad split view, and certificate pinning at the network layer.

In a cross-platform framework, every one of those points would be its own bridge to native code. You end up writing the native part anyway — on top of the framework, not instead of it. And there was a second, far more mundane reason: an Android version wasn't planned. That removed cross-platform's strongest argument before the discussion even started.

So when wouldn't we? If the same app also had to run on Android and were mostly lists, forms and uploads, one shared codebase would have been the sensible call — for us too. The decision follows the feature list, not a preference.

Time-to-market: how fast do you need to be live?

When speed matters — because you want to test a product idea or catch a market window — cross-platform plays its biggest strength. One codebase means you're live on iOS and Android at the same time, without having to keep two development tracks in sync.

For an MVP (the lean first version that gets you real user feedback), that's often the deciding factor. You want to find out whether the idea holds up — not squeeze out the last drop of performance. If the app takes off, you can still sharpen individual parts with native code later.

Maintenance: the line item many people forget

An app is never "done". Apple and Google ship new OS versions, new devices and new store requirements every year. Each of those changes needs looking after.

And this is exactly where the math gets interesting: two native codebases also means double the maintenance. Every update, every bugfix, every new feature has to be built and tested twice. With cross-platform you maintain in one place — which lowers your running costs over the app's entire lifetime noticeably, often more than the savings on the initial build.

Run the numbers instead of taking our word for it: our app support starts at €149/month, which is €1,788 a year. Over four years, maintenance alone approaches the price of an MVP — and with two separate native codebases, parts of it land twice. Anyone who factors that in from the start ends up choosing cross-platform more often, for purely economic reasons.

Native vs. cross-platform, side by side

Don't forget the backend

There's one thing the native-versus-cross-platform decision doesn't settle for you: as soon as users log in, data syncs between devices or push notifications go out, you need a backend. And the effort for it is identical in both worlds — the server can't tell whether a request came from SwiftUI or React Native.

In practice that means two things. First: never compare quotes on app technology alone when one includes the backend and the other doesn't. Second: with a cleanly defined interface, the frontend decision stays reversible. That's exactly why we cut the API frontend-neutral — a backend usually outlives the first generation of the app, and nobody wants to rebuild the foundation just because the technology in front of it changed. We've written up what such an interface looks like here: API integration: connecting your systems.

Our honest recommendation per scenario

• You want iOS and Android, a classic business app, limited budget: Cross-platform (React Native or Flutter). Best ratio of cost, speed and quality.
• You're testing an idea and want an MVP fast: Cross-platform. Live quickly, sharpenable later where it matters.
• Only one platform really matters (iOS, say): Native with SwiftUI is often the clean, low-maintenance choice — the cross-platform advantage doesn't apply here.
• Performance, animations, games, deep hardware integration: Native. Here the extra effort clearly pays off.
• You're unsure: Then a concept conversation helps more than any rule of thumb. The answer depends on your specific features and your goal — not on what's fashionable. You can look at how we work through this together beforehand.

You'll have noticed we're not selling you a favorite technology here. Our own app is native — and for a classic business app on both platforms we'd still steer you toward one shared codebase. The feature list decides, not habit.

That's the conversation we like having before the first euro is spent: send us your must-have features and we'll tell you in a free initial consultation which route is cheaper in your case — including the uncomfortable version, "you don't actually need an app for that". If you want a number to go with it first, our cost breakdown has one: app development cost.

Frequently asked questions