"Do we really need two apps?" It is one of the first questions a founder asks once an estimate comes back, and it is the right one to ask. The native vs cross-platform app decision determines whether you build and maintain one codebase or two for as long as the product lives. For most business apps, one codebase is the sensible answer. This article is about the cases where it isn't, and how to tell which side of the line your app sits on.
What you are choosing between
Native means two apps: one written in Swift, usually with SwiftUI, for iPhone and iPad, and one written in Kotlin, usually with Jetpack Compose, for Android. Each uses its platform's own tools and gets new platform features first. It also means two codebases, and usually at least two developers.
Cross-platform means one codebase for both, most often in Flutter or React Native. If you have already decided on cross-platform and are choosing between those two, our Flutter vs React Native comparison covers that decision.
There is also a growing middle option. Kotlin Multiplatform shares business logic such as networking, validation and data handling across platforms while each app keeps a native interface. JetBrains declared Compose Multiplatform for iOS stable in version 1.8.0 in May 2025, so teams can share interface code this way too.
Why cross-platform is the default for most business apps
Look at what most business apps do: booking, ordering, loyalty points, field-service checklists, customer portals, internal tools. The screens are forms, lists, maps, payments and notifications. Mature cross-platform packages cover all of those.
With one codebase, one team builds each feature once, it lands on both platforms the same day, and you fix each bug once. For a company whose app supports its business rather than being the business, that is usually the deciding factor.
Cross-platform does not remove native knowledge completely. Someone still handles store builds, code signing, yearly OS updates and the occasional native module. Plan for that skill on the team, even if it is a small part of the work.
What cross-platform still costs you
One codebase is not the same as zero trade-offs. Three costs show up in most projects, and it is better to see them in the estimate than to meet them later.
- Package risk. Many device features come from community packages. Before you depend on one for a core feature, check when it was last updated, how many issues are open and whether it supports current OS versions. An abandoned package for your card reader or Bluetooth scanner quietly becomes your team's code to maintain.
- Framework upgrades. Flutter and React Native both ship new versions several times a year, on top of the yearly iOS and Android releases. Skip a few and the eventual upgrade turns into a project of its own.
- Per-platform testing. Keyboard behavior, permissions prompts, accessibility labels and back navigation still differ between iPhone and Android. One codebase still needs testing on real devices for both.
In the native vs cross-platform app debate, these costs rarely change the answer for a typical business app. They are the price of the default, and an honest estimate includes them.
When separate native apps are worth it
These are the situations where we would seriously consider two native apps, roughly from strongest reason to weakest.
- The app's main value lives outside the app. On iPhone, home screen widgets, Live Activities, watch complications and Control Center controls are all built with Apple's WidgetKit and SwiftUI. Google's own codelab on Flutter home screen widgets says you can't draw a widget's interface with Flutter at all. If the lock screen is your product, as with a live delivery tracker or a transit app, a large share of the work is native whatever you choose.
- Wearables are central. Flutter's list of supported deployment platforms covers Android, iOS, web, Windows, macOS and Linux. watchOS is not on it. An Apple Watch app is native work.
- Continuous hardware processing is the core feature. Real-time camera analysis, augmented reality, audio processing, or a Bluetooth device streaming readings all day. The core loop will be native code either way, and a framework layer on top can become something you work around rather than with.
- You must ship new OS features within days of release. Native developers can use a new Apple or Google API as soon as it is released. Cross-platform plugins often need time to add support, and you either wait or write the native code yourself.
- You can fund two platform teams for years. Large consumer apps where platform polish is a competitive edge often run separate iOS and Android teams. That only works if the budget covers both teams for the life of the product, not just the first release.
Notice what is not on the list: "performance" in general. For forms, lists, feeds and dashboards, a well-built cross-platform app is fast enough for users not to notice. Performance becomes a reason for native only when the app does the heavy, continuous work described in point three.
The middle paths people forget
Cross-platform with native pieces. Most cross-platform apps can call native code for the one feature that needs it. Flutter does this through platform channels, React Native through native modules. An app that is almost all Flutter with a native widget extension is a normal, sensible design.
Adding to an existing native app. If you already have native apps that work, you don't have to rewrite them to go cross-platform. Flutter can be added to an existing Android or iOS app as a module that renders some screens, and React Native can likewise add a single view or user flow to a native app. New features can be built once while the proven parts stay as they are.
Shared logic, native screens. With Kotlin Multiplatform, the rules of your business are written once and each platform keeps its own native interface. This suits teams that already have Android developers writing Kotlin.
Pricing both routes for a gym chain's app
Say you are planning an app for a chain of gyms: class booking, membership payments, QR check-in at the door, push reminders, a workout log and, the marketing team's favorite, a lock-screen countdown to your next class. Here is an illustrative estimate in hours. It is not a quote, and your numbers will differ.
Cross-platform:
- app screens, logic and API integration: 600
- native lock-screen and widget pieces for iOS and Android: 80
- backend and admin panel: 350
- design: 120
- testing: 150
Total: 1,300 hours.
Two native apps:
- iOS app: 560
- Android app: 560
- lock-screen and widget pieces: 80
- backend and admin panel: 350
- design for two sets of platform conventions: 150
- testing two apps: 220
Total: 1,920 hours, about 48% more. The second app does not double the budget, because the backend, the admin panel and much of the design are shared. But it adds a large slice, and that slice is permanent: every future feature is built, tested and released twice.
For this gym app, the verdict is cross-platform with a small native piece for the lock-screen countdown. The countdown is a reason to write some native code, not a reason to write the whole app twice.
Native vs cross-platform app: a five-question check
- Is the app's main value on the lock screen, the home screen, a watch or a connected hardware device?
- Is continuous camera, AR, audio or Bluetooth processing the core feature?
- Do you need new OS features within days of Apple or Google releasing them?
- Is platform polish a competitive edge for you, and can you fund two platform teams for the life of the product, not just version one?
- Do you already have native apps that work well?
How to read the answers:
- No to all five: build cross-platform.
- Yes to question 1 or 2, but only for one feature: cross-platform, with that feature built natively.
- Yes to question 3 or 4, or yes to 1 or 2 for the core of the product: build native apps.
- Yes to question 5: keep your native apps and consider add-to-app or shared Kotlin logic for new work instead of a rewrite.
Before you ask anyone for a quote, cut the feature list down to what version one really needs. Our guide to scoping an MVP helps with that, and a shorter list often makes the native question much easier to answer.
We build native iOS apps, native Android apps and cross-platform apps in Flutter, so we have no reason to steer you to one answer. Send us the feature list through our contact page and we will tell you which approach fits and roughly what it involves.
