Native vs cross platform app development: when do you need Swift and Kotlin?

What are the options, exactly?

Native development means building a separate app for each platform in its own language: Swift for iOS and Kotlin for Android. Cross platform development means one shared codebase that ships to both. The terms get blurred, so it helps to pin them down.

Approach	What you build	Typical tools	Interface
Native	Two apps, two codebases	Swift with SwiftUI; Kotlin with Jetpack Compose	Each platform’s own components
Cross platform	One app, one codebase	Flutter, React Native	Flutter draws its own; React Native uses native components
Shared logic, native interface	One shared core, two interfaces	Kotlin Multiplatform	Native on each, or shared with Compose Multiplatform
Hybrid (web in a shell)	A web app packaged as an app	Ionic, Capacitor, Cordova	Web pages in a web view

This page is about the first decision: native or one of the shared approaches. If you have already decided on cross platform, our Flutter vs React Native guide picks between the two main frameworks. If you’re not yet sure you need an installed app at all, start with web app vs mobile app vs PWA.

What does native still do better in 2026?

Native is better at things that sit outside the main app screen, things that push the hardware hard, and things that are brand new on the platform. Inside an ordinary screen of forms, lists and buttons, modern cross platform apps are as fast and smooth as native for practical purposes.

Native keeps a real edge in four areas:

1. Extensions outside the app. Home screen widgets, watch apps, lock screen features and similar extensions are built with each platform’s own frameworks. Google’s Flutter codelab on home screen widgets says you can’t draw a widget’s interface with Flutter and instead adds widgets built in SwiftUI or Jetpack Compose. If the app’s value is mostly in those surfaces, much of the code ends up native anyway.
2. Heavy processing and graphics. Real time camera processing, augmented reality, audio work and large 3D scenes benefit from direct access to the platform’s graphics and machine learning frameworks.
3. New platform features on day one. Apple and Google release new APIs each year. Native teams can adopt them immediately; cross platform teams wait for plugin support or write the bridge themselves.
4. Platform feel. Apps that need to look and behave exactly like the platform’s own apps, including every system gesture and accessibility behaviour, get there more easily natively.

Do device features force you to go native?

Usually not. Cross platform apps can reach almost every device feature, either through a plugin or a small piece of native code. Flutter uses platform channels to call Swift and Kotlin code, and React Native uses Turbo Native Modules for the same job. The rest of the app stays shared.

Feature	Cross platform reality	When it pushes you native
Bluetooth Low Energy (scanners, sensors, scales)	Plugins exist and work well for standard devices	Custom protocols, many simultaneous devices or tight timing
NFC (tags, access cards)	Plugins cover reading and writing common tag types	Payment style card emulation or unusual tag formats
HealthKit and Health Connect	Plugins cover common data types	Clinical grade data, many data types or background sync of health data
Background location	Plugins handle tracking with the right permissions	All day tracking where battery life is critical
Camera and scanning	Plugins for capture and barcode scanning	Real time image processing or custom camera pipelines
Push notifications	Mature, standard support	Rich interactive notifications with custom interfaces

The risk to manage is plugin quality, not access. Before committing, list every device feature in the brief, check that a maintained plugin exists for each, and budget for native modules where one doesn’t. For apps used in the field without signal, our offline first field apps guide covers storage and sync, which matter more than the framework.

How do cost and timeline compare?

Native means building and maintaining the app’s interface, device code and tests twice, while design, backend and management are shared. Published Australian estimates, such as AppGurus’ 2026 cost guide, put the cross platform saving at 30 to 40% on the app compared with two native builds.

That saving applies to the mobile app, not the whole project. The backend, admin portal, integrations and data cost the same either way. Our app development cost guide works through an example where moving a Flutter app to native adds about $25,800 to a project.

Timeline follows the same pattern. Two native teams can work in parallel, so native doesn’t have to take twice as long, but it needs twice the mobile engineers to keep pace, and keeping both apps in step needs more coordination.

What does each cost to maintain?

Native doubles the ongoing work on the app itself: two sets of operating system updates, two sets of dependencies and two specialist skill sets. Cross platform puts most of that work in one place, with framework upgrades added on top.

Both stores raise their requirements every year whatever you build with. At the time of writing:

• Google Play requires new apps and app updates to target Android 16 (API level 36) from 31 August 2026, with extensions available to 1 November 2026.
• Apple has required apps uploaded to App Store Connect to be built with Xcode 26 and the iOS 26 SDK since 28 April 2026.

These deadlines are routine for an app under a support plan and painful for an app nobody has touched in two years. Team skills matter too: a native app needs someone who knows Swift and someone who knows Kotlin, or one rare person who knows both. Our guide to publishing on the App Store and Google Play covers the account and review side.

Where does native win, and where doesn’t it?

Native tends to win when the product is defined by the device; cross platform wins when the product is defined by the business process. Some illustrative patterns:

Native is usually the better spend for:

• A fitness or health product centred on a watch app and widgets.
• A camera app doing real time measurement or inspection with augmented reality.
• An app driving custom Bluetooth hardware with strict timing, such as industrial equipment.
• A consumer app competing on platform polish against well funded rivals.

Cross platform is usually the better spend for:

• A booking, ordering or loyalty app for a hospitality or service business.
• A field service app for technicians with forms, photos, signatures and offline sync.
• A member or customer portal with payments and notifications.
• An internal app for staff on company phones.

A middle path works well when one feature needs native depth: build the app cross platform and write that one feature as a native module. Both Flutter and React Native can also be embedded in existing native apps, so a mixed approach can change over time.

Is Kotlin Multiplatform a middle ground?

Yes, for teams that want native interfaces without writing the business logic twice. Kotlin Multiplatform shares code such as data models, networking and business rules across Android and iOS, while each platform keeps its own interface. JetBrains also offers Compose Multiplatform, which it describes as stable for Android, iOS and desktop, for teams that want to share the interface too.

It suits organisations that already have Android engineers working in Kotlin and want an iOS app without a full second team. It’s less common than Flutter or React Native, so hiring and plugin choice are narrower, and iOS engineers still need to know Swift for the native layer.

Where do hybrid apps and PWAs fit?

Hybrid apps and progressive web apps are web technology, so they’re the cheapest route when the app is mostly content and forms. A hybrid app wraps web pages in a native shell for the stores; a PWA is installed straight from the browser with no store at all. Both give up some device access and polish, especially on iPhone, and Apple’s review guidelines push back on apps that are little more than a repackaged website. If that trade looks acceptable, web app vs mobile app vs PWA is the better guide to read next.

Decision table

Question	If yes	If no
Is the app’s main value in widgets, a watch app or other extensions?	Lean native	Cross platform
Does it process camera, audio or sensor data in real time?	Lean native	Cross platform
Must it adopt new iOS and Android features on release day?	Native	Cross platform
Is every device feature covered by a maintained plugin?	Cross platform	Budget native modules, or native
Will one small team maintain it for years?	Cross platform	Either
Do you already have Swift and Kotlin engineers in house?	Native is realistic	Cross platform

If most answers point to cross platform, the next question is Flutter or React Native; see Flutter vs React Native.

How AWLabs approaches the choice

We build cross platform business apps in Flutter, and recommend native when the brief is dominated by platform features rather than business workflow. Either way, we list the device features up front and confirm plugin support before the Schedule of Work is fixed, so there are no surprises mid build. Senior engineers lead every build. See Flutter development and web and mobile app development.