The mobile development landscape has shifted substantially in the past two years. React Native’s new architecture is stable, Flutter has matured beyond Google’s ecosystem, and Kotlin Multiplatform has become a serious contender. If you’re choosing a mobile development strategy in 2026, here’s where things stand.

The State of React Native

React Native’s new architecture — Fabric renderer and TurboModules — has been the default since version 0.76. The performance improvements are measurable: startup time is faster, animations are smoother, and the bridge bottleneck that caused performance issues for years is gone.

The Expo ecosystem has become the de facto way to build React Native apps. Expo Router provides file-based routing (similar to Next.js), EAS Build handles cloud builds and app store submissions, and the Expo SDK covers most common native functionality without writing native code.

For teams with JavaScript/TypeScript expertise, React Native with Expo is the most productive path to cross-platform mobile development. The developer experience — hot reloading, instant previews on device, familiar React patterns — is excellent.

Where it shines: Business applications, content apps, e-commerce, social features. Apps where the UI follows platform conventions loosely rather than implementing highly custom interfaces.

Where it struggles: Performance-intensive applications (games, video editing), apps requiring deep platform integration (Bluetooth LE, custom camera pipelines), and apps where pixel-perfect platform-native UI is a hard requirement.

Flutter’s Position

Flutter remains the strongest option for custom UI. The Impeller rendering engine delivers consistent 60fps performance on both platforms, and the widget toolkit provides complete control over every pixel.

The Dart language continues to be Flutter’s biggest adoption barrier. Developers who learn Dart generally like it, but convincing a team to invest in a language used primarily by one framework is a hard sell. The hiring pool is smaller than JavaScript/TypeScript or Kotlin.

Flutter’s strength is visual consistency. If your app needs to look identical on iOS and Android — with custom animations, complex layouts, and branded UI elements — Flutter does this better than any other cross-platform solution.

Where it shines: Consumer apps with heavy custom UI, branded experiences, animation-heavy interfaces, startups that prioritise design consistency.

Where it struggles: Apps that should feel “native” to each platform, enterprise apps with standard UI patterns, and teams that can’t invest in Dart expertise.

Kotlin Multiplatform

Kotlin Multiplatform (KMP) takes a different approach: share business logic across platforms while writing native UI for each. Your networking, data processing, business rules, and local storage are written once in Kotlin. The UI layer is SwiftUI on iOS and Jetpack Compose on Android.

This gives you truly native UI on both platforms — not “native-like” but actually native. The user experience is indistinguishable from a pure native app because the UI layer is a pure native app.

The trade-off is that you’re still writing two UI layers. The shared business logic typically represents 40-70% of the codebase, so you’re saving significant effort, but not as much as a fully cross-platform solution.

Companies like Netflix, VMWare, and Cash App have adopted KMP in production, lending credibility to the approach.

Where it shines: Apps where platform-native UI is essential, teams with Kotlin and Swift expertise, projects where business logic is complex but UI is straightforward.

Where it struggles: Small teams without resources to maintain two UI layers, rapid prototyping scenarios, and projects where development speed matters more than native feel.

When to Go Fully Native

Pure native development (Swift/SwiftUI for iOS, Kotlin/Compose for Android) still makes sense in specific scenarios:

• Your app relies heavily on platform-specific features (ARKit, HealthKit, Android Auto)
• Performance is critical (games, real-time audio/video processing)
• You have dedicated iOS and Android teams
• Your app is a core differentiator for your business and needs to feel premium on each platform

The cost is roughly double the development effort compared to cross-platform approaches. For well-funded companies where mobile is the primary product, this investment is justified.

PWAs: The Forgotten Option

Progressive Web Apps deserve mention because they’re often overlooked in the native-vs-cross-platform debate. For apps that don’t need native features — news readers, internal business tools, content platforms — a well-built PWA provides a solid mobile experience with a single web codebase.

PWA support on iOS has improved steadily. Push notifications, offline support, and home screen installation all work. The gap between a PWA and a native app is smaller than many developers assume, especially for content-focused applications.

My Decision Framework

1. Do you need native platform features? If yes, how deep? Light integration (camera, location) works fine cross-platform. Deep integration (custom Bluetooth protocols, ARKit) requires native.

2. What’s your team’s existing expertise? JavaScript teams should look at React Native. Kotlin teams should look at KMP. Teams with no mobile experience should start with React Native or Flutter for the fastest path to a working app. I’ve seen AI consultants in Melbourne help companies assess their existing team capabilities before committing to a mobile platform, which saves months of wasted effort going down the wrong path.

3. How important is platform-native UI? If users expect the app to feel like a “real” iOS or Android app, KMP or native is the answer. If custom branding matters more than platform conventions, Flutter excels.

4. What’s your timeline? For MVPs and prototypes, cross-platform tools save months. For long-term products, invest in the approach that matches your team’s growth plan.

There’s no universally correct answer. The best mobile strategy depends on your specific constraints — team skills, timeline, budget, and what your users actually need.