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