u/starling-dev

Starling is a full Linux DE where the whole desktop — compositor, dock, window manager, apps — is one native Swift program. The unusual parts, in repo terms:
sdk/ — Flutter’s widget framework ported to Swift (element tree, render objects, gesture arena — the framework, not bindings), driving Flutter’s C engine core directly. No Dart VM.

shell/Sources/WaylandServer/ — its own Wayland compositor, ~5k lines of plain C.

shell/Sources/X11Server/ — an in-tree X11 server (DRI3/Present) so legacy apps run too; Chrome, VS Code, Blender, and Zoom run unmodified.

Renders straight through DRM/KMS — no toolkit, no host compositor.

The 0.3.0 release that just shipped adds a workspace mode built for AI agents: the agent drives from its own room, and every window it opens is claimed for that room by client identity — never lands on your desktop. 3:49 unedited demo: https://starling.build/video/agent-workspace.mp4

Also fun: the project is ~7 months of one person directing AI agents, and the .deb ships only after a gate that installs it on a clean Ubuntu 26.04 VM and logs in through real GDM.

Release notes: https://github.com/starling-build/starling/releases/tag/v0.3.0

Happy to answer anything about the compositor, the framework port, or the workflow.

Starling SDK is Flutter’s framework ported to Swift, running directly on the Flutter engine’s C core. No Dart in your project — you write the widget tree in Swift.
Column(mainAxisAlignment: .center) {
Text("Hello from the Starling SDK", style: TextStyle(fontSize: 30))
SizedBox(height: 18)
GestureDetector(onTap: { setState { taps += 1 } }) {
Text("Tap me")
}
}

Your application writing in Starling sdk will run on Windows and Linux.
Getting started (both platforms): https://starling.build/start.html
Release: https://github.com/starling-build/starling/releases/tag/sdk-v0.2.0

Starling SDK is Flutter’s framework ported to Swift, running directly on the Flutter engine’s C core. No Dart in your project — you write the widget tree in Swift:

Column(mainAxisAlignment: .center) {
Text("Hello from the Starling SDK", style: TextStyle(fontSize: 30))
SizedBox(height: 18)
GestureDetector(onTap: { setState { taps += 1 } }) {
Text("Tap me")
}
}

New in 0.2.0 is a Windows bundle. Apps are hosted by the engine’s own Win32 embedder (flutter_windows.dll) driven in Swift mode, so windowing, input, IME and accessibility come from the same code path real Flutter Windows apps use — the same arrangement as the GTK host on Linux. The framework itself turned out to be remarkably portable: across all 325 files of the framework sources, exactly one real compile error (M_E, which the UCRT hides).

It ships as a download-and-point bundle — the framework plus the engine binaries it links against, in one tree. Unpack it, add a path dependency, swift build.

Getting started (both platforms): https://starling.build/start.html
Release: https://github.com/starling-build/starling/releases/tag/sdk-v0.2.0

Starling 0.2.3 — what’s new:
• Screen recording — whole screen or one window, hardware-encoded
• Control centre
• Notifications
• Task Manager
• A video player that decodes on the GPU
• Terminal ~4x faster
4-min demo, recorded by the desktop itself:
https://starling.build

A while back I posted the Linux desktop we built on a Swift port of Flutter's framework. The most common question was about the port itself, so: it's now usable on its own, without the desktop.

The framework — widgets, rendering, painting, gestures, animation, semantics — is ported from Dart to Swift, with everything below unchanged: Skia, the text stack, the platform embedders. There's no Dart VM; where the engine would start an isolate it starts a Swift runtime instead. The Linux host is the engine's own GTK embedder, so windowing, input and IME come from the same
code path a normal Flutter Linux app uses.

The port is close to mechanical, so Flutter's concepts carry over intact — StatefulWidget, setState, BuildContext, constraints down and sizes up. Same counter app, same structure. The main difference is Swift's result builders: containers take trailing closures, so `if` and `for` work directly inside a widget tree.

We did it because we're building system software where the language mattered, not because there's anything wrong with Dart. Flutter's the reason any of this was possible.

Linux x86_64 today, macOS next. BSD-3, inherited from Flutter.

https://starling.build/sdk.html
https://github.com/starling-build/starling/tree/main/sdk

We ported Flutter's framework to Swift — widgets, rendering, painting, gestures, animation, semantics — running on Flutter's own C++ engine. No Dart
VM: the engine starts a Swift runtime where it would normally start a Dart isolate.

The result is a declarative, cross-platform GUI framework you can use from Swift today on Linux. Apps run on any ordinary session (GNOME, KDE, X11) through the engine's GTK embedder. If you've used Flutter or SwiftUI the model will be familiar; if you've used neither, Flutter's own docs apply almost
directly.

Trying it is one download — the bundle ships the engine binaries, so there's no engine build. Install, depend on it by path, `swift build`. Tested on Swift
6.2.4 and 6.3.3.

Linux x86_64 today; macOS is next but not yet verified.

Getting started: https://starling.build/start.html
More detail: https://starling.build/sdk.html
Source: https://github.com/starling-build/starling/tree/main/sdk

Built with AI assistance under my direction, in case that matters to you.

This isn't a rice — it's a desktop environment I wrote from scratch. I got
tired of configuring one, so I built one.

**Specs**
- **Distro:** Ubuntu 26.04 LTS
- **DE:** Starling (mine — its own Wayland compositor + X11 server, no
existing WM underneath)
- **Compositor:** 5,860 lines of hand-written C — xdg-shell, linux-dmabuf
(zero-copy), viewporter, fractional-scale, pointer-constraints, text-input-v3
- **Shell/apps:** Swift, on a from-scratch port of Flutter's framework
(~222k lines, no Dart VM)
- **Terminal:** mine (real PTY), Roboto Mono
- **Wallpaper:** Golden Gate at dusk (bundled)
- **Bar/dock/launcher:** all mine — dock, Launchpad, Mission Control
- **Source (Apache-2.0):** github.com/starling-build/starling

**How it works:** no X11 or Wayland session underneath — it drives the GPU
directly via DRM/KMS and *is* the display server. It boots as a normal
unprivileged session through GDM. Third-party apps composite as native
clients: Chrome, VS Code, IntelliJ, GIMP, Blender (EEVEE viewport through the
dma-buf path).

Tiling is master-and-stack, toggled from Settings; there are spaces with a
Mission Control overview. Because every window is a widget in the framework,
tiling is just a layout and Mission Control is just an animated grid — it works
on real third-party apps for free.

Early preview (v0.2), so: no screen lock yet, scaling pinned to 2.0, AMD and
virtio-gpu tested. Installs from a .deb: https://starling.build

Sharing something unusual: Starling, a Linux desktop environment — shell,
window manager, its own Wayland compositor, first-party apps — where the
entire UI layer is a from-scratch port of Flutter's *framework* to Swift, running on Flutter's *engine* C core. No Dart VM.

The part I think is genuinely interesting to this community isn't Swift. It's what it says about Flutter's architecture: the embedder API is a clean enough seam that you can replace the whole framework layer above it and the engine
doesn't care. Skia, the compositor, the raster/UI thread model, the platform channels — all of it kept working while Dart went away.

The port follows the framework's own structure (Widgets, Rendering, Painting, Gestures, Animation, Scheduler, Semantics), and the API is deliberately
recognizable:

override func build(_ context: any BuildContext) -> Widget {
return DecoratedBox(
decoration: BoxDecoration(color: pal.background),
child: Column(children: [
Expanded(flex: 4, child: _display()),
Expanded(flex: 3, child: _row([...])),
]))
}

StatelessWidget, StatefulWidget, State, BuildContext, Element, InheritedWidget — same concepts, same lifecycle, ~190k lines of Swift.

It also runs on a **DRM/KMS embedder**: no X11, no Wayland client, no windowmanager under it. Flutter drives the GPU directly and *is* the display server —
the desktop composites real third-party apps (Chrome, VS Code, IntelliJ, GIMP, Blender) as Wayland/X11 clients into the widget tree. Once another app's window is a widget, tiling is a layout and Mission Control is an animated grid.

Why not just use Dart? Fair question, and the honest answer is that this is a system component: it spawns and supervises child processes, talks DRM/KMS,
libinput, dma-buf and D-Bus, and lives or dies on C interop. That's a job the Dart FFI could do but Swift does more naturally, and it let the shell and the
framework be one language end to end. It's a trade, not a verdict on Dart —and the engine being reusable *unchanged* is the point I'd want a Flutter dev to take away.

Early preview, honest about it: v0.2, Ubuntu 26.04, AMD + virtio-gpu tested,
scaling pinned to 2.0. Also worth stating plainly: it was largely written by AI
(Claude) under my direction.

Site + screenshots: https://starling.build
Architecture rationale: https://starling.build/why.html
Source (Apache-2.0): https://github.com/starling-build/starling

Happy to go deep on the embedder, the framework port, or how much of the
engine we had to touch (less than you'd think).