Native or Cross-Platform? Choosing How Your Mobile App Gets Built
Flutter, React Native, Swift and Kotlin compared for business apps — what each approach is good at, where the real cost difference sits, and how to pick without over-engineering.
One codebase, two app storesFIG.01
Short answer
Cross-platform frameworks such as Flutter and React Native build one codebase that ships to both iOS and Android, and that suits most business apps. Native — Swift for iOS, Kotlin for Android — earns its extra cost when the app needs heavy graphics, deep hardware access or same-day support for new OS features.
Key takeaways
- Cross-platform is the sensible default for business apps; native should be a decision you can justify, not the starting assumption.
- The cost difference is less about the first build and more about maintenance — two codebases means every change is made twice, forever.
- Native still wins on heavy graphics, sustained background work, deep hardware access and day-one support for new OS releases.
- A cross-platform app can drop into native code for the one screen that needs it, so the choice is not all-or-nothing.
- Users almost never notice the difference. Your team and your budget do.
This decision is usually made for the wrong reason: someone has heard that native is "better quality" or that cross-platform is "cheaper". Both statements are too crude to act on. What actually differs is where the cost sits over the app's life, and which capabilities you can reach.
The four options, briefly
- Native — Swift for iOS, Kotlin for Android. Two separate apps, written with the platform's own tools.
- Flutter — Google's framework. One codebase, draws its own interface, compiles to both platforms.
- React Native — one codebase in JavaScript or TypeScript, rendering real platform components.
- Webview wrapper — your website packaged as an app. Cheap, and almost always a disappointment for anything beyond a simple catalogue.
| Native (Swift / Kotlin) | Flutter | React Native | |
|---|---|---|---|
| Codebases to maintain | Two | One | One |
| Interface | Platform-native by definition | Drawn by Flutter; consistent across both | Real platform components |
| New OS features | Available immediately | Waits for framework support | Waits for framework support |
| Heavy graphics / games | Best | Good | Weakest of the three |
| Deep hardware access | Direct | Via plugins, or a native module | Via libraries, or a native module |
| Team you need | iOS and Android developers | Flutter developers | Developers who know React |
| Sharing code with your website | No | Limited | Yes, if the site is React |
What cross-platform is genuinely good at
Most business apps are forms, lists, status screens, a camera, notifications and a connection to a back end. Both Flutter and React Native handle all of that comfortably, and one codebase means a change requested on Monday ships to both platforms in the same release.
That matters more than it sounds. The cost of an app is not the first version — it is the two years afterwards, where every fix, every new field and every regulatory change is either one piece of work or two.
When native earns its cost
- Sustained background work — continuous location tracking, long uploads, audio that must survive the app being backgrounded.
- Heavy or custom graphics: real-time rendering, AR, anything game-like.
- Deep or unusual hardware: specialised Bluetooth peripherals, NFC edge cases, camera control beyond taking a photo.
- You need new iOS or Android capabilities the day they ship, rather than when a framework catches up.
- The app is your product rather than a channel to it, and platform polish is part of what customers are buying.
Apple and Google both publish their platform expectations — the iOS Human Interface Guidelines and Android's design guidance — and they are worth reading whichever route you take, because a cross-platform app that ignores platform conventions feels wrong in ways users report as "slow" even when it is not.
The part that is not all-or-nothing
Both Flutter and React Native let you write native code for a specific piece and call it from the shared codebase. So the realistic question is not "native or cross-platform" but "is there any part of this app that needs native, and how big is it?"
If the answer is one screen out of thirty, build cross-platform and write that screen natively. Choosing two full native codebases because of one requirement is how budgets get spent on nothing anyone uses.
What this changes about hiring and handover
Native means finding and keeping both iOS and Android skills, or accepting that one platform lags. Flutter means a smaller hiring pool than web developers but a focused one. React Native means the people who maintain your website may be able to maintain your app, which is a real advantage for a small team.
Whichever you choose, the handover requirements are the same: your own repository, your own app store accounts, signing keys in your possession, and documentation. App store accounts registered in a vendor's name are a genuinely painful problem to unwind later.
How to choose
Choosing a mobile development approach
List what the app must do on the device itself
Camera, location, offline storage, printing, Bluetooth, background work. Ignore anything that is really a server feature.
Mark anything on that list that is unusual
Taking a photo is ordinary. Continuous background location for eight hours is not. Only the unusual items push toward native.
Decide whether both platforms are actually needed
Check what your users carry. Building for one platform first is a legitimate way to halve the cost of finding out whether the app is useful.
Cost the second year, not the first
Estimate the changes you expect after launch, then double them for native. That is the number the decision turns on.
Check who will maintain it
Pick the option your team — or the market you hire from — can actually support in three years.
Before you choose the technology at all
The build approach matters less than the scope. A tightly scoped first release tells you whether the app is worth investing in, and which features belong in a mobile MVP is the more valuable decision to get right first. What app development costs covers the budgeting side.
If you have a list of features and no strong view on the technology, that is a good position to be in. Send us the list — the right approach usually falls out of the requirements rather than the other way round.
Frequently asked questions
Is a cross-platform app slower than a native one?
For ordinary business apps — forms, lists, status screens, a camera — the difference is not something users notice. It becomes measurable in graphics-heavy work and sustained background processing.
Flutter or React Native?
If your web team already works in React, React Native keeps the skills in one place. If the app is standalone and you want a consistent interface across both platforms, Flutter is the tidier choice. Neither is a mistake.
Can we build for Android first and add iOS later?
Yes, and with a cross-platform codebase the second platform is mostly testing and store submission rather than a rebuild. With native it is a second project.
Will Apple or Google reject a cross-platform app?
No. Both stores judge what the app does and how it behaves, not the framework used to build it. Rejections come from policy issues — permissions, privacy disclosures, payment rules — which apply equally to native apps.
We only need an app so customers can check their orders. Do we need one at all?
Possibly not. If the need is occasional lookups, a fast mobile website avoids the install barrier entirely. An app earns its place when people use it often enough to want it on their home screen.
/Services in this article
/Related project previews
See the ideas in production
Keep reading
All articlesMobile App MVP: The 7 Features You Should Build First
A practical way to scope a first mobile release around one valuable user journey instead of an expensive list of untested features.
Software for Distribution Businesses: Orders, Stock and Recovery
How distributors and wholesalers get orders, inventory, dispatch and credit recovery into one system — and which module to build first.