The cross-platform question is usually argued with a four-year-old statistic and a preference. This chapter gives you the current state of each option, what each genuinely solves, what each is genuinely wrong for, and a decision framework that does not require picking a winner.

This is the item most candidates are stalest on. The rewrite that replaced the asynchronous bridge with a synchronous native interface completed:

So “is the New Architecture optional?” has a clean answer: no. The legacy components were deleted in February 2026. Anyone describing it as a migration you can defer is describing 2024.

What React Native uniquely solves is not code sharing — it is over-the-air updates. You can ship a JavaScript bug fix without an app store review cycle. That single capability is why it survives in product organisations that measure time-to-fix, and it is a genuine architectural advantage rather than a convenience.

What it is genuinely wrong for: anything where the JavaScript thread is the bottleneck — real-time graphics, camera and augmented-reality pipelines, audio signal processing, high-frequency gesture-driven canvases. And it is wrong for a team with no native engineers at all: removing the bridge did not remove Xcode, Gradle, provisioning profiles or dependency managers. Note also that the framework's own documentation now steers new projects to Expo — bare React Native is the unusual choice in 2026.

Version 3.47 (12 August 2026) made three changes that matter architecturally: the Material and Cupertino design systems became opt-in standalone packages, decoupling design-system releases from the SDK; the newer rendering engine became the default on desktop platforms, eliminating first-play shader stutter; and web is moving toward WebAssembly by default.

What Flutter uniquely solves: pixel-identical rendering everywhere, because it draws every widget itself rather than wrapping platform ones. Plus best-in-class hot reload and a genuine six-target story. For design-led products where brand consistency beats platform convention, nothing else is close.

What it is genuinely wrong for: anything that must feel like a native OS application — because it renders its own widgets, accessibility, text selection and platform-idiom behaviours are approximations. Anything with heavy native SDK integration, since every plugin is a bridge somebody maintains. And web, where the bundle size and absence of a real DOM make it unsuitable for anything indexable.

This is the genuinely distinct bet and the one most people misunderstand. Kotlin Multiplatform lets you share networking, persistence, business logic and models while writing SwiftUI on iOS and Compose on Android. Sharing the UI as well — via Compose Multiplatform — is an optional extra step, not the premise.

That means it is the only mainstream option that keeps 100% native UI fidelity. If your objection to cross-platform has always been “it never quite feels right”, this is the answer to that objection.

• Compose Multiplatform for iOS reached stable in May 2025 — real iOS scroll physics, native text selection, accessibility wiring.
• Compose Multiplatform for web is beta, not stable. Stable means Android, iOS and desktop. That distinction is exactly the kind of thing an interviewer probes, and getting it right signals you checked rather than assumed.
• Named production users include a major streaming service, a payments app, a document editor's iOS client, a language-learning app and a cloud provider's SDK. Reported adoption of over fifteen thousand production apps is press-sourced rather than vendor-published — use it as direction, not fact.
• Wrong for: teams without existing Kotlin and Android expertise — the on-ramp is Gradle and native tooling, which is brutal for a JavaScript team. Also wrong for web as a primary target, and anywhere you need a large third-party component ecosystem.

Google declared Android UI development ‘Compose-first’ on 19 May 2026. All APIs, libraries, tooling and guidance go to Compose first; the classic view system, fragments and the older list components move to maintenance mode — explicitly not deprecated, still getting critical fixes, but no new features. All new Android Studio UI tooling is Compose-only.

On Apple's side, SwiftUI is the default for new projects and receives the majority of the UI innovation. The honest teaching line is: SwiftUI is mature enough to build a whole app in, and still has escape hatches you will use — the representable wrappers — for list performance edges, complex text input and anything not yet wrapped. “SwiftUI or UIKit” is now “SwiftUI with UIKit where it does not reach”, not a fork in the road.