App Developmentblockchain app development

Cross-platform or native in 2026: Flutter, React Native, Kotlin Multiplatform and the native route

Updated 7 min readBy Davinder Kumar Meen

Two phones side by side with flowing orange lines across their screens

For most business apps in 2026, a cross-platform framework is the sensible default, and native is the exception you choose for a specific reason. Flutter, React Native and Kotlin Multiplatform with Compose Multiplatform are all mature enough for production; the choice depends on your team's skills and how closely you need to match each platform. Choose native Swift and Kotlin when the app depends heavily on platform features or the very latest platform design. All of them must still meet the same store rules, and those rules change every year.

Key takeaways

  • React Native made the New Architecture the default in 0.76 (23 October 2024), and 0.82 (8 October 2025) was "the first React Native that runs entirely on the New Architecture". The latest release listed is 0.87 (11 August 2026).
  • Flutter's latest stable release is 3.47 (12 August 2026).
  • Compose Multiplatform for iOS reached stable in version 1.8.0 in May 2025; JetBrains reports about 9 MB of extra app size against a native SwiftUI app with the same UI. Web support (Wasm) is still in beta.
  • Since 28 April 2026, apps uploaded to App Store Connect must be built with Xcode 26 or later using an iOS 26 SDK; from 31 August 2026, new apps and updates on Google Play must target Android 16 (API level 36).
  • The store requirements apply whichever approach you choose, so budget for yearly maintenance.

Should we build one app for both platforms or two native apps?

Start from what the app needs, not from the technology.

If the app... Lean towards
Is a typical business app: lists, forms, accounts, payments, notifications Cross-platform (one codebase)
Needs to launch on iOS and Android at the same time with one team Cross-platform
Depends heavily on platform-specific features, such as deep camera, sensor or system integrations Native, or cross-platform with native modules
Must adopt a new platform design the day it ships Native
Already has a strong native team on one platform Native for that platform, and a plan for the other

Cross-platform does not mean "no native code": most real apps include native modules or platform-specific screens somewhere. The question is how much of the app can be shared.

How do the main options compare?

Option Language What it is Current state (sourced)
Flutter Dart One toolkit and codebase for mobile, web and desktop Latest stable 3.47 (12 August 2026)
React Native JavaScript or TypeScript with React Native interface built from React components Latest release 0.87 (11 August 2026); New Architecture only since 0.82
Kotlin Multiplatform with Compose Multiplatform Kotlin Shared Kotlin logic, with a shared Compose interface if you want one Compose Multiplatform for iOS stable since 1.8.0 (May 2025)
Native iOS Swift Apple's own tools Xcode 26 and the iOS 26 SDK required for uploads since 28 April 2026
Native Android Kotlin Google's own tools New apps and updates must target API level 36 from 31 August 2026

React Native

React Native lets a team that already knows JavaScript or TypeScript and React build mobile apps. The framework spent 2024 and 2025 moving to its New Architecture: version 0.76 (23 October 2024) made it the default, 0.80 (12 June 2025) froze the legacy architecture, and 0.82 (8 October 2025) was "the first React Native that runs entirely on the New Architecture". The project says it will remove remaining legacy code "to reduce install size and streamline the codebase". It ships a release roughly every two months, so keep upgrades on your plan. If your website already runs React or Next.js, sharing skills and some logic is a real advantage.

Flutter

Flutter draws its own interface from one Dart codebase, which makes designs look the same on every platform and gives close control over animation. The documentation covers setup for Android, iOS, web, Windows, macOS and Linux. Flutter 3.47 (12 August 2026) made the Widget Previews tool stable. The trade-off is that your team works in Dart, and the interface matches the native look only as far as you build it to.

Kotlin Multiplatform and Compose Multiplatform

Kotlin Multiplatform shares Kotlin code between platforms, and Compose Multiplatform can share the interface too. JetBrains announced Compose Multiplatform for iOS as stable and production-ready in version 1.8.0 in May 2025, and says all major APIs are stable. It reported about 9 MB of extra size compared with a native SwiftUI app with the same UI, and that over 96% of teams using it on iOS report no major performance concerns; both figures are JetBrains' own. Its FAQ lists Compose Multiplatform as stable for Android, iOS and desktop, with web support based on Wasm still in beta. It suits teams that already work in Kotlin.

Native Swift and Kotlin

Native gives the closest fit to each platform and the earliest access to new platform features. It also means two codebases and, usually, two skill sets. Apple's current design language, Liquid Glass, and Google's Material 3 Expressive both show where each platform is heading; see UX and UI design trends in 2026.

What do the stores require, whichever you choose?

Apple's upcoming-requirements page says: "Apps uploaded to App Store Connect must be built with Xcode 26 or later using an SDK for iOS 26, iPadOS 26, tvOS 26, visionOS 26, or watchOS 26." This has applied since 28 April 2026. Google Play requires that from 31 August 2026, new apps and updates target Android 16 (API level 36) or higher, with exceptions for Wear OS, Automotive OS, Android TV and Android XR; developers can request an extension to 1 November 2026. A cross-platform framework does not exempt you: you must keep the framework, its plugins and the build tools current. Treat that as an ongoing cost when you compare options.

How do you choose?

  1. List what the app must do on day one. If nothing needs deep platform access, cross-platform is usually enough.
  2. Look at your team. React and TypeScript skills point to React Native; Kotlin skills to Kotlin Multiplatform; a team starting fresh can pick Flutter or native.
  3. Decide how closely the look must match each platform. Native and React Native follow platform controls closely; Flutter gives you uniform, custom design.
  4. Plan the maintenance. Budget for yearly store-required upgrades and for framework releases.
  5. Prototype the riskiest feature first, such as payments, maps or offline sync, before committing.

Our hybrid app development and Flutter app development pages list the frameworks we work with, and iOS development and Android development cover native work. For the wider decision, see How to choose a tech stack for a web or mobile app in 2026, and for design, our app design page.

FAQ

Is cross-platform slower than native?

It depends on the app. Each framework can deliver smooth performance for typical business apps, and each has limits for graphics-heavy or sensor-heavy ones. Test the screens that matter most on real devices before you commit.

Is React Native or Flutter better?

Neither is better in general. React Native fits teams that already use React and TypeScript; Flutter fits teams that want one custom design on every platform and are happy to work in Dart. Compare them on your team's skills, your design needs and the plugins you rely on.

Can we start cross-platform and move to native later?

Yes, but plan for it: keep business logic separate from the interface, and write down which parts depend on platform features. Moving screens one at a time is easier than a full rewrite.

Do we have to keep updating the app?

Yes. Apple and Google raise their build and target requirements each year (Xcode 26 and iOS 26 SDK since 28 April 2026; Android 16 and API level 36 from 31 August 2026), and frameworks release often. Budget for regular maintenance.

What happened to the older advice about native versus hybrid?

Older guides compared native apps with web-based hybrid wrappers. The modern frameworks above compile to native code or draw their own interface, so the question has moved from "native or hybrid" to how much of the app you can share and how closely it must follow each platform.

Sources

Share this article