Starling: a Linux desktop environment written in Swift, with its own Wayland compositor

What Starling is trying to replace, and for whom

A Linux desktop environment is normally assembled from parts written in C, C++, Vala and JavaScript: a compositor, a shell, a toolkit, a settings daemon, and a set of applications that each pick their own stack. Starling collapses that into one language. The shell, the compositor, the framework and the first-party apps are all Swift, and the framework is a full port of Flutter's Dart framework to Swift with no Dart VM. The project runs on the Flutter engine's C core through a sibling repository called starling-engine, and on the Flutter-to-Swift port in a sibling repository called flutter-swift.

The intended audience is narrow. This is not a distribution or a desktop for end users who want something that works today. It is for engineers who want to read a compositor and a window manager in a single language, and for Swift developers who want to see whether the toolchain holds up outside Apple platforms. The README says the project is the work of one person and a few months, and that nothing in it is load-bearing for anyone yet.

How the shell, compositor and framework fit together

The repository is a workspace of sibling checkouts rather than a single build tree. Two symlinks hold it together: sdk points at a flutter-swift checkout (the SwiftPM package FlutterSwift), and engine points at a starling-engine checkout. bootstrap.sh creates those links. From there, shell/ contains the desktop shell as the SwiftPM package DesktopShellApp, apps/ holds one SwiftPM package per first-party application, and host/ contains a windowed host (FlutterRunner plus GLFWBridge) that runs a Swift Flutter app in an ordinary window for demos.

The compositor itself is around 5,700 lines of C inside the shell, implementing xdg-shell, linux-dmabuf for zero-copy import, viewporter, fractional-scale-v1, pointer-constraints, relative-pointer, text-input-v3, presentation-time, primary-selection, idle-inhibit, cursor-shape-v1, xdg-decoration, xdg-activation, xdg-output and wlr-data-control. So the split is deliberate: the protocol server stays in C where the Wayland ecosystem already lives, and everything above it, including the window manager, dock, spaces and portals, is Swift.

The session does not run as root. It boots through the normal login path, gdm3 to gdm-wayland-session to /usr/libexec/starling-session to DesktopShellApp --drm, and gets DRM master and input from logind through libseat. Display handling covers DRM/KMS modeset, GBM/EGL, a hardware cursor, flip-driven frame pacing and multi-output layout. The README states testing on AMD (Radeon 780M) and on virtio-gpu/virgl in a VM, which is a small hardware matrix for a compositor.

Installing Starling on Ubuntu 26.04 and running the session

The README points to docs/INSTALL.md as the starting point and describes a .deb as the packaging route. The package is 50.8 MB and installs on a minimal Ubuntu 26.04 image, pulling 26 dependency packages; the Depends field is computed from the shipped binaries by dpkg-shlibdeps. The repository also lists docs/BUILDING.md for building from source, and bootstrap.sh links the two sibling checkouts that the build needs. Because the SDK and engine are separate repositories, a source build starts with those symlinks rather than with the .deb.

The documented boot path is the normal login flow, so the session appears in gdm3 as a selectable session after installation. The command that the session launcher ultimately runs is:

/usr/libexec/starling-session

That script starts the shell with the DRM backend:

DesktopShellApp --drm

Once inside, the window manager offers floating and tiling (master-and-stack) behind one switch, spaces with a Mission Control overview, drag-move and drag-resize, a dock with running indicators and drag-to-reorder, and a Launchpad. Nine first-party apps ship with it: Settings, Files, Terminal, Text Editor, Calculator, App Store, Task Manager, Video Player and Image Viewer. The Terminal runs a real PTY.

For third-party software the README describes two paths. Native packaging is the expected route; alternatively app-run expects a debootstrap'd runtime under /var/lib/starling-apps, which the README calls opt-in and unshipped. The App Store catalog has ten entries, and the README notes that tiles use category glyphs rather than vendor artwork on purpose, because those logos are their owners' trademarks. Chrome and VS Code show real icons in the launcher and dock, read from the host at runtime; the other ids fall back to a generic glyph.

Where Starling breaks: stale output state, a partial portal, and no lock screen

The README's known-limitations list is unusually direct, and several items are structural rather than cosmetic. The clearest is xdg_output: state is sent once and never updated. A client that asks for an xdg_output receives the logical position and size as they are at that moment, and a later mode change, scale change or output hotplug does not re-send them. A long-running client can therefore be left with stale geometry. The README says the resources are not tracked per output, which is what fixing it needs, so this is an architecture gap rather than a missing branch.

The portal is incomplete in a way that is easy to miss. Settings and FileChooser work, and both carry the version property that clients probe first. Inhibit, Camera and Print are absent entirely. The session bus masks the stock xdg-desktop-portal rather than letting it fill those gaps, because it has no backend for Starling and would serve only its backend-less interfaces while taking org.freedesktop.portal.Desktop away from the shell's own portal, breaking the two that do work. That is a defensible trade, but it means screen sharing through the portal works while camera access does not.

Other gaps: there is no screen lock or screensaver at all. Scaling is effectively pinned to 2.0, because fractional values produced blurry text and are not usable yet. There is no display-mode selection; the session takes the connector's preferred mode, and overriding it means editing the session launcher. The third-party app runtime is opt-in and unshipped, so a user who expects the App Store to be a general software channel will be disappointed. Zoom is catalogued but starts with no audio, reporting no pactl and pacmd found; the README says that is deliberate, because Zoom segfaults during audio init when pactl is on PATH on a PipeWire box with no native PulseAudio daemon, which is the stock Ubuntu 26.04 arrangement.

How Starling differs from GNOME Shell and KDE Plasma

GNOME Shell and KDE Plasma are the obvious alternatives, and the difference is not features. Both are mature environments with years of hardware coverage, stable portal backends, screen locking, fractional scaling that works, and distribution packaging that has been exercised on far more machines than AMD Radeon 780M and virtio-gpu. Starling has none of that.

The real difference is the stack. GNOME Shell is JavaScript on top of Mutter, a C compositor built on Clutter; Plasma is C++ with QML and KWin. Starling replaces the toolkit layer entirely with a Flutter-to-Swift port and writes the shell in Swift against it, so an application and the shell share one framework and one language. That is the whole bet: a smaller number of moving parts, at the cost of a framework port that has to reach parity with Flutter's Dart implementation on its own. The 137 test files under sdk/Tests are the visible measure of how far that port has been taken, and the README does not claim parity.

If you need a working desktop, Plasma or GNOME is the answer. If you want to study or extend a compositor and shell written in one language, Starling is one of very few places where that exists.

Editorial conclusion

Starling is for people who want to read and modify a desktop environment at the source level, and for Swift developers curious how far the language reaches outside Apple platforms. It is not for anyone who needs a daily driver: there is no screen lock, the portal is incomplete, and the README states that interfaces change without notice. Before adopting anything, verify the boot path on your own hardware, since the README documents testing on AMD (Radeon 780M) and on virtio-gpu/virgl in a VM, and confirm that the missing portal interfaces (Inhibit, Camera, Print) do not matter for the apps you run.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. starling-build/starling on GitHub