Starling Turns Flutter Into a Full Linux Desktop Environment
Starling demonstrates that a UI framework's retained-mode scene graph and GPU compositor can replace the entire display server layer, collapsing the stack that normally separates app toolkits from window managers. For developers watching the convergence of system and application rendering, this is a working proof-of-concept running real X11 and Wayland clients on bare DRM/KMS.
Starling is a 335,000-line open-source project that creates a complete Linux desktop environment by rewriting Flutter's Dart framework in Swift and keeping the Flutter Engine as the GPU compositor. It boots directly to DRM/KMS, bypassing Wayland compositors like Mutter or KWin, and runs its own Wayland and X11 servers to host external applications.
External app windows from Chrome, VS Code, or Blender are treated as Flutter TextureWidgets, so title bars, shadows, rounded corners, and animations all live inside the same Flutter layer tree. The project already supports multi-monitor setups, tiling, Spaces, Mission Control, a Dock, and first-party Swift apps for settings, file management, and a terminal.
A key architectural inversion is at play: instead of Flutter apps running on top of a desktop compositor, the Flutter framework itself becomes the compositor. The Dart-to-Swift port preserves Flutter's widget, element, and render-object model, including setState and the multi-child diffing algorithm, while mapping Dart mixins to Swift protocols and class hierarchies.
Starling inverts the standard Linux graphics stack: the UI framework is no longer a client of the compositor but is the compositor itself, which eliminates an entire layer of scene-graph duplication between the toolkit and the display server.
Treating external app windows as TextureWidgets means every window automatically inherits Flutter's animation, clipping, and compositing capabilities without per-app cooperation, a model that could simplify desktop effects infrastructure.
The Dart-to-Swift port is mechanically faithful rather than idiomatic, suggesting the goal was preserving Flutter's exact rendering and layout semantics rather than creating a SwiftUI-like API.
Building a custom Wayland server and X11 server from scratch instead of using wlroots or XWayland gives Starling full control over buffer handling and texture registration but multiplies the protocol surface the project must maintain.