Flutter vs React Native — what changes once you've shipped both

"Flutter or React Native?" is the question every mobile dev eventually gets asked. After more than 6 years shipping production apps — including real projects in both, not just tutorials — I've landed on an answer that isn't about which framework is "better" in the abstract. It's about what each one costs you day to day.

The difference that matters most: who draws the screen

Both follow declarative UI, but they get there through very different paths.

React Native uses JSX and resolves the interface by bridging over to native components — the same mental model as someone coming from web front-end.

Flutter has no bridge: it draws its own widget tree directly, with Dart compiling to native code. That shows up in practice — no bridge latency, no "this library doesn't have a native binding for this RN version."

The classic "hello world" already makes this visible:

// React Native
import React from 'react';
import { StyleSheet, Text, View } from 'react-native';

const App = () => {
  return (
    <View style={styles.container}>
      <Text>Hello world!</Text>
    </View>
  );
};

const styles = StyleSheet.create({
  container: {
    flex: 1,
    backgroundColor: '#fff',
    alignItems: 'center',
    justifyContent: 'center'
  }
});

export default App;

// Flutter
import 'package:flutter/material.dart';

void main() {
  runApp(
    const Center(
      child: Text(
        'Hello, world!',
        textDirection: TextDirection.ltr,
      ),
    ),
  );
}

It's not just fewer lines — it's fewer moving parts in transit. In React Native, styling, layout, and the native component behind it live in three different places that need to agree with each other. In Flutter, it's all the same tree.

Where each one gave me the most trouble

I worked with React Native on products ranging from a smart home app (sensor control, 3D visualization) to virtual reality projects. The recurring friction wasn't writing the logic itself — it was every time the app needed something RN didn't cover natively: that's when it turns into a native module, into debugging Swift/Kotlin underneath a JS abstraction, into Fast Refresh — which is supposed to be fast — turning into a noticeably slower rebuild cycle than Flutter's Hot Reload.

With Flutter, the friction moves elsewhere: less "this library doesn't support that," more "I need to write this native integration myself via a platform channel" — which takes more upfront setup, but fewer surprises later.

Differences that matter in practice

What I'd actually recommend

Starting a new project today: I go with Flutter, no hesitation. The predictability of owning the entire rendering tree pays off the Dart learning curve — especially as the app grows and maintenance starts to matter more than initial setup.

That's not saying React Native is a bad choice — entire teams (Meta, Airbnb for a while, Discord) prove it scales. It's saying that, in my track record, the maintenance cost paid off more on the Flutter side than the learning cost paid off on the RN side.

The right question isn't "which framework is better." It's "which friction would I rather pay: learning Dart now, or depending on someone else's native module later?"