Go native, with Swift and SwiftUI on iOS and Kotlin and Jetpack Compose on Android, when the device or the platform is central to your product: hardware integration, demanding camera, audio or graphics work, widgets and wearables, or new operating system features on release day. It is also the right call for large consumer apps that can fund two specialised teams. For most internal and business apps, native is more than you need, and a cross-platform framework ships the same result with one team.
Native development has never been the wrong answer technically. The question is whether its advantages are worth maintaining two apps for years. Here is how we judge that.
What going native means in practice
A native app uses each platform's own language, UI toolkit and tools.
| iOS | Android | |
|---|---|---|
| Language | Swift | Kotlin |
| Modern UI toolkit | SwiftUI (UIKit still underneath and alongside) | Jetpack Compose (Views still supported) |
| IDE | Xcode | Android Studio |
| Where new features appear | Apple's SDKs, announced at WWDC each June | Android releases and Jetpack libraries |
Both platforms have converged on the same idea: declarative UI, where you describe what the screen should show for a given state and the toolkit works out the updates. Google describes Jetpack Compose as Android's recommended modern toolkit for building native UI, and Apple continues to put its new UI work into SwiftUI; this year's WWDC26 releases, iOS 27 and Xcode 27, again brought SwiftUI additions such as new toolbar and document APIs. A developer who knows one of SwiftUI or Compose recognises most of the other, although they remain two languages and two ecosystems.
When native is the right call
The device is the product. Bluetooth peripherals, NFC, medical or industrial hardware, custom camera pipelines, AR, low-latency audio. Cross-platform frameworks reach these through native modules, which means you write Swift and Kotlin anyway, plus a layer in between.
Platform features on day one. Home screen widgets, watch and car apps, Live Activities, App Intents and system assistant integration, new design language changes. They arrive as native APIs first; cross-platform support follows, sometimes months later.
Native feel is how you compete. Banking, health and consumer apps are judged side by side with Apple's and Google's own apps. Native controls, gestures, accessibility and system behaviour come for free and stay current when you rebuild with a new SDK.
You can staff two teams for the long run. Large apps often end up with separate iOS and Android teams whichever technology they start with. If you will have them anyway, native lets each team use the best tools for its platform.
Heavy background work and tight performance budgets. Long-running sync, location tracking, large offline datasets and complex rendering are easier to tune when nothing sits between your code and the operating system.
When native is more than you need
Most business apps are screens of lists, forms, detail views, a camera for photos, a barcode scanner, push notifications and an offline cache. Every serious cross-platform framework does all of that well. Building it twice buys very little.
- Internal and field apps for technicians, sales teams and warehouse staff, where consistency and reliability matter more than platform polish.
- A first version whose job is to test whether customers want the product at all.
- Small teams who would otherwise ship every feature twice and test it twice, and keep both apps in step on every release.
For these, Flutter or React Native is the usual answer, and a web-based app can be enough for simpler tools.
What drives the cost of two codebases
We will not put a multiplier on it, because it depends on the app. What drives it is predictable:
- Every feature is built, reviewed and tested twice. Shared design and a shared API reduce the thinking, not the typing.
- Keeping parity. Two apps drift. Someone has to own the rule that a feature is not done until both platforms have it, or users on one platform wait.
- Two sets of skills. Hiring, code review and holiday cover for Swift and for Kotlin, not one pool.
- Two yearly upgrade cycles. Each new iOS and Android release brings SDK requirements, deprecations and store policy changes.
The rest of the budget (backend, API, design, testing on devices, store releases) is the same whichever way you build the UI. What drives mobile app cost and timeline covers the full picture.
Going native without doubling everything
- Write the API contract first. One documented API, versioned, shared by both apps. Most parity bugs start as two teams reading an endpoint differently.
- Keep business rules on the server where you can. Pricing, validation and permissions decided server-side are decided once.
- Share logic with Kotlin Multiplatform if rules must run on the device. Offline apps often need the same calculations locally. KMP shares that code while both UIs stay native; see Kotlin Multiplatform: when to choose it.
- Use one design system with platform variants. Shared tokens for colour, type and spacing; platform-appropriate controls.
- Release together. One release checklist and one version number for both apps. Releasing to the App Store and Google Play covers the store side.
If you are unsure whether your app needs native, list the device features and platform integrations it must have at launch and in the next year, and compare that list with the overview in choosing a mobile app framework. Our mobile app development team builds both ways and can help you decide.
Questions we get asked
Is native app development better than cross-platform?
Native is better when the app depends on device hardware, the newest platform features or a fully native feel, and when you can fund two specialised teams. For most business and internal apps, cross-platform frameworks such as Flutter and React Native deliver the same result with one codebase, so native adds cost without a matching benefit.
Should I use SwiftUI or UIKit for a new iOS app?
Start with SwiftUI for new iOS apps. It is Apple's modern declarative UI framework and where Apple adds most new UI features each year. UIKit is still fully supported and sits underneath and alongside SwiftUI, so you can drop into it for specific screens or controls where SwiftUI does not yet do what you need.
Should I use Jetpack Compose or XML views for Android?
Use Jetpack Compose for new Android apps. Google describes it as Android's recommended modern toolkit for building native UI, and most new Android libraries and samples assume it. The older View system with XML layouts is still supported and interoperates with Compose, which helps when modernising an existing app screen by screen.
Can native iOS and Android apps share code?
Yes, with Kotlin Multiplatform. It shares Kotlin code such as business logic, networking and local storage between Android and iOS while both apps keep their native SwiftUI and Jetpack Compose interfaces. Google officially supports Kotlin Multiplatform for sharing business logic, and it can be introduced one module at a time into existing apps.