If your app has to run on both iPhones and Android phones, there are two broad routes. You can build two native apps, one in Swift for iOS and one in Kotlin for Android, each with its own codebase. Or you can build one cross-platform app with a framework such as React Native or Flutter, and ship it to both stores from a shared codebase.
Both routes are mature. React Native was open-sourced by Facebook in March 2015, and Flutter 1.0 was released by Google in December 2018. On the native side, Apple introduced SwiftUI in June 2019 and Google released Jetpack Compose 1.0 in July 2021, which made native interface code much faster to write than it used to be. The choice is no longer between a good option and a bad one, but between two sets of trade-offs.
The main options in 2026
- Native: Swift and SwiftUI for iOS, Kotlin and Jetpack Compose for Android. Two codebases, each using the platform's own tools.
- React Native: JavaScript or TypeScript, with platform-native interface components. Its New Architecture has been on by default since version 0.76, released in October 2024.
- Flutter: the Dart language, with Flutter drawing its own interface, so the app looks the same on both platforms unless you choose otherwise.
- Kotlin Multiplatform: shared business logic in Kotlin, declared stable by JetBrains in November 2023, with the interface either native on each platform or shared through Compose Multiplatform, whose iOS support became stable in May 2025.
How they compare
| Question | Native (two apps) | Cross-platform (one app) |
|---|---|---|
| Codebases to maintain | Two | One, plus some platform-specific code |
| New OS features | Available right away | Often needs a plugin or a framework update first |
| Platform look and feel | Native by default | Close, with some care |
| Demanding graphics, audio, or sensors | Strongest option | Possible, with more effort |
| Team you need | iOS and Android skills | One shared skill set |
| Cost of each new feature | Built twice | Built mostly once |
When native earns its cost
- The app leans on device capabilities: Bluetooth hardware, background location, augmented reality, heavy audio or video processing.
- You need new operating system features the day they ship, such as widgets or new platform integrations.
- Performance is part of the product, as in games, drawing tools, or real-time media.
- You only need one platform, for example an iPad app for your own staff.
When cross-platform is the sensible default
- The app is mostly forms, lists, bookings, payments, and messages, which describes most business apps.
- You need both stores at launch, on a budget that cannot carry two teams.
- Features must reach iOS and Android users at the same time.
- Your developers, or the team that will inherit the code, already know JavaScript or TypeScript.
There is also a middle path: share the business logic with Kotlin Multiplatform and keep a native interface on each platform. It suits teams that want platform-perfect screens without writing every rule twice.
What stays the same either way
Some costs do not change with the framework. Both stores review every release; Apple says that on average, 90 percent of submissions are reviewed in less than 24 hours, but a rejection still adds days. Both platforms raise their requirements every year: Google Play has required new apps and updates to target Android 16 (API level 36) since August 31, 2026, and Apple has required uploads to be built with Xcode 26 or later since April 28, 2026. Whatever you choose, budget for yearly upkeep.
You also still need testing on real devices, accessibility work on both platforms, store listings, privacy disclosures, and a back end that both apps talk to. These shared costs are a large part of any mobile budget, so the gap between the two routes is usually narrower than a first comparison of codebases suggests.
A short decision checklist
- List the device features the first two releases need. Any that a cross-platform framework cannot reach well?
- Decide whether both platforms must launch together.
- Ask who will maintain the app after launch, and what they know.
- Prototype the riskiest screen or device feature in the chosen framework before committing.
Key points
- Both routes are mature; the choice is about trade-offs, not quality.
- Native wins on device features, new OS features, and demanding performance.
- Cross-platform wins on cost and speed for typical business apps.
- Store review and yearly platform updates apply either way.
Sources
- Engineering at Meta, "React Native: Bringing modern web techniques to mobile" (March 26, 2015); React Native blog, "React Native 0.76" (October 23, 2024).
- Google Developers Blog, "Flutter 1.0: Google's Portable UI Toolkit" (December 4, 2018).
- Apple Newsroom, WWDC 2019 developer technologies announcement (June 3, 2019); Android Developers Blog, "Jetpack Compose 1.0" (July 28, 2021).
- JetBrains, "Kotlin Multiplatform Is Stable" (November 1, 2023) and "Compose Multiplatform 1.8.0" (May 6, 2025).
- Apple Developer, "App Review" and "Upcoming Requirements"; Android Developers, "Target API level requirements for Google Play apps".