Native vs cross-platform apps: when native is still worth it

For most business apps, cross-platform is the right choice. One React Native or Flutter codebase produces both the iPhone and Android apps for roughly 20 to 40 percent more than building one platform, while two native apps in Swift and Kotlin cost roughly 1.6 to 2 times as much as the cross-platform build and need two teams kept in step. Native is still worth it for games, apps built around heavy camera, audio or video processing, apps whose main value is a platform feature such as widgets or a watch app, and large products with separate iOS and Android teams already in place.

Our mobile app development work is cross-platform React Native, with native modules in Swift or Kotlin where a library does not exist. The rest of this post explains the options, what each costs, and the specific cases where we tell clients to go native anyway.

What is the actual difference between native and cross-platform?

"Native" means writing each app in the platform's own language and UI toolkit: Swift and SwiftUI for iOS, Kotlin and Jetpack Compose for Android. "Cross-platform" means one codebase that builds both apps. There are four approaches in use as of October 2026:

The native multiplier is a planning ratio, not a fixed rule; the gap depends on how much of the project is backend and admin, which is shared whatever you choose. How much a mobile app costs has the full price ranges by feature.

Kotlin Multiplatform deserves a mention because it is the newest serious option. It shares business logic, and optionally the interface through Compose Multiplatform, while letting each platform keep native screens where it matters. The Kotlin Multiplatform documentation explains the model. It suits teams that already write Kotlin for Android; it is a harder sell for a business hiring its first app team.

How much more does native really cost?

Two native apps mean every feature is designed once, built twice, tested twice and fixed twice. The design and backend are shared, which is why the multiplier is below 2. The bigger cost is over time:

• Two teams to keep in step. Features ship on one platform first and the other catches up. Bugs exist on one side and not the other.
• Two sets of upgrades. Each yearly OS release needs work in two codebases.
• Two hiring problems. You need an iOS developer and an Android developer, and cover for each when they leave.

That is why we default to one shared codebase. For a business with one app and one budget, a single codebase is the difference between an app that keeps improving and one where half the budget goes on parity.

When is native the right call?

We recommend native in five situations:

1. Games and 3D. Use a game engine or native graphics. Neither React Native nor Flutter is built for this.
2. Heavy real-time media. Live video effects, audio processing, frame-by-frame camera analysis. Cross-platform can call native code for these, but when the native code is most of the app, write the app natively.
3. The platform feature is the product. A widget-first app, an Apple Watch app, CarPlay or Android Auto, deep accessibility services. These are native work regardless, so the shared codebase saves little.
4. You are only building for one platform. If your users are, say, a fleet of company Android devices and iOS will never matter, a single Kotlin app is a reasonable choice. You lose the option to add iOS cheaply later, so be sure.
5. You already have native teams. A company with established iOS and Android teams should not tear them down to adopt React Native for one new feature.

Notice what is not on the list: "performance" for a business app, "it feels more premium", or "the big companies do it". Many large apps run partly or fully on React Native or Flutter.

What about features cross-platform cannot reach?

Some things need native code even inside a cross-platform app: home-screen widgets, Live Activities, share extensions, App Clips, watch companions and a few hardware integrations. These are built as small native extensions alongside the shared app, typically in days or a couple of weeks each.

The real limit is timing. When Apple or Google launches a new capability at its developer conference, native developers can use it in the first beta. Cross-platform apps wait for a library update or write the bridge themselves. If being first with each new OS feature is central to your product, that delay matters. For a booking, ordering, field-service or membership app, it does not.

Is wrapping your website in an app a shortcut?

Hybrid tools such as Capacitor put your existing web app inside an app shell, with plugins for the camera, push and storage. If you already have a good mobile web app and need it in the stores for staff, it can be the cheapest route.

For a customer-facing app, it is usually a false saving. The result scrolls and responds like a web page, and Apple's App Store Review Guidelines (section 4.2, Minimum Functionality) reject apps that are only a repackaged website. If the website is what customers need, a progressive web app gives you installs and offline use without the store. If they need an app, build an app.

How should you decide for your app?

Answer these four questions in your mobile app brief:

• Which devices do your users have? Both platforms, or one?
• What does the app do that a website cannot? If the answer is a platform feature (widgets, watch, CarPlay), lean native. If it is push, camera, location or offline, cross-platform covers it.
• Who will maintain it in three years? One team is easier to keep than two.
• What is the budget for year two? Two native apps double the maintenance line as well as the build.

If the answers point to cross-platform, the next decision is between React Native and Flutter. Run your feature list through the app cost calculator to see the range for a cross-platform build or a single platform, and read the mobile app development guide for the decisions that come after the framework.