If your app is mostly forms and lists, a cross-platform framework is fine. If it needs the camera all day, think again. Most of the native versus cross-platform decision comes down to that, but the question usually arrives framed as cost: which one is cheaper for the first version? The choice also sets who you hire, how fast a fix reaches both platforms, and how much work it takes the first time you need something the framework does not give you.
What the two approaches actually are
A native app is written separately for each platform in that platform's own language: Swift for iOS, Kotlin for Android. A cross-platform app shares one codebase across both, using a framework such as Flutter or React Native, which then talks to iOS and Android underneath.
| Native | Cross-platform | |
|---|---|---|
| Codebases and team | One per platform, iOS and Android skills | One shared, plus native skills on call |
| Device features | Direct access to camera, sensors, Bluetooth | Through the framework or custom native modules |
| Heavy graphics | Steadier for games, AR, live video | Fine for content, forms and bookings |
| Shipping a change | Built and tested twice | Built once, still tested and submitted twice |
The claim that cross-platform is cheaper holds for a first version with ordinary screens. A catalogue, a cart, order tracking and a returns form are ordinary screens. It holds less well once the app leans heavily on the device, and much less well once a feature needs code the framework does not have.
Where "one codebase" stops being one
- Shared app codescreens, logic
- FrameworkFlutter or React Native
- Native modulescamera, GPS, Bluetooth, UPI
- iOS and Androideach with its own rules
The native modules layer is where most of the surprises live.
When a feature has no ready-made module, somebody writes native code for each platform and connects it to the framework. That is why teams find that "one codebase" still needs an iOS person and an Android person within reach.
Take a D2C brand that sells sunglasses on its own site and on the marketplaces and wants a try-on camera in its first app. The framework gives you a camera. It does not give you that camera, with face tracking and frames drawn over a live preview at a steady frame rate. The native work to build it is the same whether or not the rest of the app is shared, and it is usually the part that decides the schedule.
The same goes for things that run when the app is closed. Background location for a delivery fleet, a Bluetooth printer at a counter, a step counter that keeps going overnight. Each of these is governed by OS rules that differ between iOS and Android and change with OS versions, and a framework can only smooth over so much.
Which way your app leans
- Camera, AR or live video all day
- Background location or Bluetooth
- Audience mostly on one platform
- Polish matters more than launch date
- Launch on both platforms together
- Forms, lists, bookings, content
- Tight budget, broad reach
- Frequent changes on both platforms
Plenty of apps sit in both columns; check the hardest features before choosing.
Read it as a set of choices, not a verdict. Camera-heavy and sensor-heavy work pushes towards native because the app needs direct, low-level access and steady timing. Forms, lists, bookings and content push towards a shared codebase because the screens look the same on both platforms and most of the effort is in business logic anyway.
If your audience is mostly on budget Android phones, test either option there. A Flutter app and a Kotlin app can both feel fine on a flagship and both struggle on a phone with 3 GB of RAM and twenty other apps open. Framework choice will not save a heavy screen; careful work on that screen will.
Build a proof of the hardest feature
Before committing, list the three hardest features and build a small proof of the worst one in the approach you are leaning towards. Offline sync for field reps, background location for drivers, the try-on camera. Make that one thing work on a real phone, then on the cheapest phone your users have. A proof like this takes days, not months, and it shows whether the framework handles it cleanly or needs native modules.
Do the same exercise for updates. Ask how a change to the OTP login screen reaches both platforms, who tests it on each, and how long store review takes. The answer tells you whether a shared codebase saves effort in your case or just moves it somewhere else. Remember that both routes still go through two stores; sharing code does not share review queues.
Then count the people. A cross-platform framework saves money only if the team you have, or can hire, can maintain it. A native build only works if you can staff both platforms, and keeping one iOS developer on retainer for an Android-first audience is a cost that never appears in the first estimate.
How the decision goes wrong
The decision gets made on the estimate for version one, not on the first three years of updates. A framework is picked because the team already knows it, and nobody checks what the app needs from the device. Native modules turn up in month four and were never in the plan.
Platform conventions get ignored too. Back buttons, permission prompts, share sheets and system dialogs behave differently on iOS and Android, and users notice when an app gets them wrong. A shared codebase still needs somebody who knows both sets of rules. And then an OS update or a framework upgrade lands in the middle of the festive sale, and nobody has time set aside to deal with it.
For some products the right answer is neither. If the app is mostly content and the users will not install much, a progressive web app can cover a first version from the browser.
A one-afternoon exercise before you choose
- List every device feature the app depends on.
- Mark each as standard (camera capture, location, push) or unusual (custom camera view, background tracking, Bluetooth hardware).
- Prototype the hardest unusual one in the approach you favour, on a real phone.
- Count the people each option needs for the next three years, not the next three months.
- Write down the choice and the reason, so it can be revisited when requirements change.
Step one does most of the work. Once the device feature list is on paper, the answer is usually plain to everyone in the room. The platform decision then becomes one input to the rest of the plan, which our post on the mobile app development lifecycle walks through stage by stage, and our mobile app development page covers both routes.
