Flutter

Google‘s open-source cross-platform UI framework — one Dart codebase compiled to mobile (iOS/Android), web, desktop, and embedded. It’s the wiki’s first native/mobile ui-framework (the founding corpus was terminal + web), the widening the spoke’s charter anticipated. Paged from flutter-performance-200-hours.

Where it sits in the stack

Flutter is a textbook instance of this spoke’s rendering-core → reconciler → framework model (ui-framework), with one radical choice at the bottom:

Declarative widgets — the UI is a function of state, described as an immutable widget tree (the framework layer).
The element tree = the reconciler — Flutter diffs the rebuilt widget tree against a persistent element tree, reusing elements and updating only what changed. This is the same job React’s reconciler does in opentui/web, under different names — a direct parallel to the spoke’s reconciler thread.
It owns the canvas — unlike DOM- or platform-widget frameworks, Flutter renders every pixel itself through its own engine (Skia, now Impeller). That’s the extreme form of the spoke’s “surface as a swappable back-end” thesis: Flutter doesn’t adapt to the platform’s UI toolkit, it brings its own renderer and paints the whole surface, so the same widget tree looks identical everywhere.

The other bargain: compose-multiplatform

Flutter’s all-or-nothing sharing has a foil now. compose-multiplatform, as shipped in people-in-space, covers Android, Wear OS, desktop and web — but that project writes its iOS client in SwiftUI by hand against the same shared Kotlin. Where Flutter makes “one tree, every surface” a property of the framework, the Kotlin stack leaves the shared/native line adjustable per platform. Same goal, different place to draw the boundary; see ui-framework for the axis.

The performance model

Because the UI is rebuilt from state, rebuilds are the central performance concern — but by design, not by fault: flutter-performance-200-hours stresses that rebuilds are how Flutter works, and the win is cutting the unnecessary ones (widgets that rebuild when their inputs didn’t change), found by profiling first. The reconciler makes rebuilds cheap; sloppy widget structure makes them frequent. This is the reactive-rendering cost that any declarative UI framework shares, surfaced here in Flutter’s terms.

What the canvas bet costs — and what it’s shedding (3.44)

flutter-3-44 (2026-07) is the first release-level view of the framework here, and it reads as a bill for owning the canvas. The engine work is all pixels Flutter has to produce itself: Impeller Vulkan memory-cache and sync improvements, signed-distance functions to remove aliasing from circles and complex shapes, getUniformFloat() for binding fragment-shader uniforms by name. Hybrid Composition++ (Android, opt-in, API 34+) is the escape hatch — Vulkan hardware buffers and SurfaceControl to compose native views into the surface. Even accessibility gets re-implemented rather than inherited: web prefers-reduced-motion, aria-description on form errors, iOS motion preferences, percentage announcements on progress indicators — behavior a DOM-based framework gets from the platform, Flutter re-implements per surface.

Two structural changes in the same release:

Material and Cupertino are frozen at their final in-framework versions and move out to standalone material_ui / cupertino_ui packages. Flutter shipped framework and design system as one artifact for years; unbundling puts its top rung on its own cycle, where every other source in this spoke already had it.
Desktop gets windows. Experimental windowing APIs (main channel) bring popup windows, real child windows for showDialog, content-sized views on Linux — and Canonical takes over as lead maintainer of the Linux/Windows/macOS embedders. One canvas per app becomes several.

Also in 3.44: Swift Package Manager as the iOS/macOS default over CocoaPods, Android Gradle Plugin 9.0 forcing a plugin-side 3.44 minimum, and native-ARM tooling that drops the Rosetta dependency on Apple Silicon.

Agent access to the running app

flutter-3-44 gives agent-ready-ui its most concrete instance so far. Agentic Hot Reload lets coding agents connect to a running app and reload it; Agent Skills for Dart/Flutter package task guidance the way opentui does; and the MCP server’s tool definitions were consolidated to reduce agent token cost. That last one is an API-surface decision made on what a model pays to read it — harder to dismiss as documentation quality than the claims the founding sources made. (Flutter’s GenUI SDK, where agents compose UI at runtime, sits on the other side of the seam in ../agentic-tooling-wiki.)

Connections across the family

Flutter is a graph hub across three spokes: its language is Dart (in ../dev-tooling-wiki), and the 2D game engine Flame (in ../game-engines-wiki) is built on it — so a Flutter app, a Flutter game engine, and the Flutter language now each sit in the spoke that owns their respective layer (UI framework here, language as toolchain there, engine there), cross-linked rather than duplicated.

flutter-3-44 · flutter-performance-200-hours · ui-framework · opentui · dart · flame-engine · google · compose-multiplatform · people-in-space · design-system · agent-ready-ui · synthesis