How does Flutter render UI without a bridge, and what does the widget tree actually compile to?

This question probes whether a candidate actually understands Flutter's rendering model or just knows it "looks the same on both platforms." The honest, differentiating answer is that Flutter does not use native UI widgets at all — no UIView, no android.view.View for your app's UI — and that choice is the reason Flutter needs no bridge in the first place. There is nothing to bridge to, because Flutter draws every pixel itself.

#Dart compiles to native code, and the engine owns the canvas

In release mode, Dart is ahead-of-time (AOT) compiled straight to ARM/x64 machine code — it is not interpreted at runtime the way the old bridge model needed JS to be. In debug mode it runs just-in-time (JIT) instead, which is what makes hot reload possible: the running Dart VM can swap in new compiled code without restarting the app. Either way, your widget code runs as native code calling directly into the Flutter engine, a C++ runtime embedded in the app. The engine, in turn, hands drawing commands to a graphics backend — Skia historically, and increasingly Impeller, Flutter's newer rendering backend that precompiles shaders ahead of time to avoid the runtime shader-compilation jank Skia was prone to on first paint. Either backend talks straight to the GPU. Native platform code only enters the picture for things Flutter does not draw itself: camera access, Bluetooth, native SDKs — anything that needs a platform channel.

#Three trees, not one

The part almost everyone forgets to mention: what you write is not directly what gets drawn. Flutter maintains three parallel trees. The Widget tree is what your build() methods return — immutable, cheap, and completely rebuilt on every frame that touches it. The Element tree is the persistent structure that actually manages state and does the reconciliation: on each rebuild, Flutter diffs the new widget against the old element's widget (by runtime type and key) and either updates the existing element in place or tears it down and creates a new one. The RenderObject tree is what actually performs layout (a single pass, mostly, computing size and position) and paint (turning layout results into a display list handed to the engine).

This is why const constructors matter for performance, not just style: a const widget is a compile-time constant, so on rebuild Flutter can skip even the diff — it is provably the same instance. It is also why keys matter when reordering a list of stateful widgets: without a matching key, Flutter's element diffing matches by position and type, and can wrongly reuse an element (and its state) for what is conceptually a different item.

class ProductCard extends StatelessWidget {
  const ProductCard({super.key, required this.title, required this.price});

  final String title;
  final double price;

  @override
  Widget build(BuildContext context) {
    return Card(
      child: Padding(
        padding: const EdgeInsets.all(12),
        child: Column(
          crossAxisAlignment: CrossAxisAlignment.start,
          children: [
            Text(title, style: Theme.of(context).textTheme.titleMedium),
            const SizedBox(height: 4),
            Text('\$${price.toStringAsFixed(2)}'),
          ],
        ),
      ),
    );
  }
}

#Rebuilds are scoped, not global

Calling setState on a State object schedules a rebuild of that widget's subtree only — not the whole app. Flutter walks down from the dirtied element, rebuilds widgets, diffs each against its existing element, and only the RenderObjects whose layout or paint actually changed do new work. This is conceptually close to React's reconciliation (an immutable description diffed against a persistent tree), but there is no separate "commit to the DOM" step with its own async scheduling quirks — the Element and RenderObject trees already are the retained, mutable structures the engine paints from.

class Counter extends StatefulWidget {
  const Counter({super.key});

  @override
  State<Counter> createState() => _CounterState();
}

class _CounterState extends State<Counter> {
  int _count = 0;

  void _increment() => setState(() => _count++);

  @override
  Widget build(BuildContext context) {
    return Row(
      children: [
        Text('$_count'),
        IconButton(onPressed: _increment, icon: const Icon(Icons.add)),
      ],
    );
  }
}

#Where native code still shows up: platform channels

For anything Flutter cannot or should not reimplement itself — battery level, native SDKs, platform-specific permissions dialogs — Dart talks to native code through a MethodChannel, an explicit, named, message-passing boundary that is used sparingly, not on every frame:

class BatteryService {
  static const _channel = MethodChannel('com.example.app/battery');

  Future<int> getBatteryLevel() async {
    final level = await _channel.invokeMethod<int>('getBatteryLevel');
    return level ?? -1;
  }
}