| 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
|