Framework comparison — 14 features

React Native vs Flutter vs Kotlin Multiplatform

Strength / supported
Gap / weakness
Feature React Native Flutter Kotlin Multiplatform
Animation
  • Reanimated 3 runs on the UI thread for native-feel gestures
  • Native Animated API for simple transitions
  • Custom painting/shaders still need native code
  • Rich built-in animation APIs, consistently high frame rates
  • Full custom painting via CustomPainter/Canvas
  • Rive and Lottie are first-class
  • Compose Multiplatform shares Compose's animation APIs (iOS stable since CMP 1.8)
  • Fully native UI path means animations aren't shared, written twice
Third-party libraries
(Maps, Stripe, etc.)
  • Huge npm ecosystem, most major SDKs have RN wrappers
  • New Architecture compatibility still a per-library check
  • pub.dev has mature packages for maps, payments, auth
  • Google is Flutter's own vendor — Google APIs integrate especially well
  • Smaller multiplatform ecosystem, many libraries need expect/actual wrappers
  • Native SDKs drop in directly per platform when UI is native
Native integrations
(device APIs, native modules)
  • TurboModules + JSI give direct, synchronous native calls
  • Large catalog of community native modules
  • Platform channels (MethodChannel) for calling native code
  • More ceremony than RN — every call crosses a channel
  • expect/actual resolves at compile time — no runtime bridge
  • Can call any native SDK directly from the actual implementation
Web support
  • Not first-party — relies on community react-native-web
  • Workable if the UI is mostly views/text
  • Official first-party target, stable since 2021
  • Larger initial bundle; SEO needs extra work
  • Compose Multiplatform for web now in beta
  • Not yet as mature as the Android/iOS targets
Desktop support
(Windows/macOS/Linux)
  • Not official — react-native-windows/-macos lag behind, community-run
  • Official, stable target for all three desktop OSes
  • Compose Multiplatform for Desktop is stable (JVM-based)
UI rendering model
  • Renders real native UIKit/Android views via Fabric — native look by default
  • Draws every pixel itself (Skia/Impeller) — platform look must be hand-matched
  • Identical pixel output on both platforms
  • Default path uses 100% native UI components per platform
  • Optional Compose Multiplatform path draws its own widgets, like Flutter
Performance
  • Near-native since the New Architecture removed the async bridge
  • Still runs a separate JS engine alongside native
  • Compiles to native ARM/x64, consistently high frame rates
  • Skia/Impeller engine adds baseline memory/startup overhead
  • Shared logic compiles straight to native code — no interpreter, no bridge
  • Native-UI path has zero rendering-layer overhead
Hot reload / dev speed
  • Fast Refresh — near-instant JS-only changes
  • Native module changes still need a full rebuild
  • Stateful hot reload — widely considered best-in-class
  • Platform-channel changes still need a rebuild
  • No true hot reload on the Kotlin/Native (iOS) side
  • Android side gets Compose live edit; CMP tooling improving
Language & learning curve
  • JavaScript/TypeScript — largest hiring pool of the three
  • Still need some native Swift/Kotlin for deeper modules
  • Dart is used almost nowhere else — net-new language for most hires
  • Very consistent single language across the whole app
  • Kotlin is already familiar to every Android developer
  • iOS developers still need Kotlin plus Swift for native UI
State management
  • Many mature options — Redux, Zustand, Jotai, React Query
  • Official, opinionated options (Provider, Riverpod, Bloc)
  • Shared ViewModel/StateFlow in common Kotlin works across platforms
  • Needs platform-specific glue to observe from SwiftUI
Testing
  • Jest + React Testing Library; Detox/Maestro for E2E
  • Built-in widget testing + integration_test — most cohesive of the three
  • kotlin.test runs shared-logic tests once across every target
  • UI tests still written per platform (XCTest / Espresso)
App size
  • Hermes engine keeps baseline small (~7–10MB overhead)
  • Engine + Skia/Impeller adds meaningfully to baseline (~5–10MB+)
  • Native-UI path adds almost nothing beyond the shared library
  • Compose Multiplatform path adds engine overhead like Flutter's
Community & backing
  • Oldest of the three (2015), largest ecosystem, backed by Meta
  • Years of old/new-architecture package fragmentation
  • Very large, fast-growing ecosystem, strong Google backing
  • Younger than RN — some enterprises still cautious
  • Smallest ecosystem, especially for ready-made UI-sharing libraries
  • Backed by JetBrains + Google; Jetpack libraries now ship multiplatform
Adding to an existing native app
  • Well-trodden path, official brownfield integration guide
  • Supported via add-to-app, but more setup friction than RN
  • Designed for this from day one — least friction of the three