Starling SDK 0.3.0 — macOS joins Linux and Windows, and starling-create

Download-and-point SDK bundles: the Flutter→Swift framework plus the engine binaries it links against, in one tree. No engine checkout needed.

New in this release: macOS, and with it all three desktops. Apps are hosted by the engine's own Cocoa embedder (FlutterMacOS.framework) driven in Swift mode — the counterpart of the GTK host on Linux and the Win32 host on Windows.

Also new: starling-create. One file, no repo to clone. It picks the bundle for the machine it runs on, caches it under ~/.starling/sdk, and writes a SwiftPM project wired to it:

curl -fLO https://github.com/starling-build/starling/releases/download/sdk-v0.3.0/starling-create
chmod +x starling-create
./starling-create myterm && cd myterm && swift run -c release

Those four lines are the same on all three platforms — on Windows in Git bash. --template app scaffolds a plain window instead of a terminal; --sdk takes a URL or a local archive when you want a bundle other than this one. A Swift toolchain is the only prerequisite.

Install by hand instead

# Linux x86_64
curl -LO https://github.com/starling-build/starling/releases/download/sdk-v0.3.0/starling-sdk-0.3.0-linux-x86_64.tar.gz
sudo tar -xzf starling-sdk-0.3.0-linux-x86_64.tar.gz -C /opt/

# macOS arm64
curl -LO https://github.com/starling-build/starling/releases/download/sdk-v0.3.0/starling-sdk-0.3.0-macos-arm64.tar.gz
sudo tar -xzf starling-sdk-0.3.0-macos-arm64.tar.gz -C /opt/

# Windows x86_64
curl.exe -LO https://github.com/starling-build/starling/releases/download/sdk-v0.3.0/starling-sdk-0.3.0-windows-x86_64.zip
Expand-Archive starling-sdk-0.3.0-windows-x86_64.zip -DestinationPath C:\

Then depend on it by path — see https://starling.build/start.html.

Contents. Framework sources, Examples/, and the engine built at release config for each platform:

	engine/lib/	engine/share/
Linux	libflutter_engine.so, libflutter_linux_gtk.so, libflutter_linux_drm.so	icudtl.dat, flutter_assets
macOS	FlutterMacOS.framework, libswift_bridge.dylib	flutter_assets
Windows	flutter_engine.dll, flutter_windows.dll, each with its .lib import library	icudtl.dat, flutter_assets

Four things to know.

Your manifest imports FlutterGTK on Linux, FlutterCocoa on macOS, FlutterWin32 on Windows; everything else is identical, except that the Ubuntu 26.04 -Xcc math .unsafeFlags are Linux-only and must not be copied into a macOS or Windows manifest.

macOS has no icudtl.dat in engine/share, and that is deliberate. The framework already carries the trimmed build Flutter actually uses at FlutterMacOS.framework/Versions/A/Resources/icudtl.dat; the 10 MB file beside a mac engine build is full ICU, for the engine's own tests. The hosts look inside the framework first.

The Windows bundle also carries Vendor/conpty/ — conpty.dll and OpenConsole.exe. They matter only if you use TerminalView: without them it still works, silently falling back to the inbox console host at roughly three times the CPU on the read path.

No bundle carries the Swift runtime — that belongs to your toolchain, exactly as libswiftCore does on Linux. On Windows its absence is 0xC0000135 before main(), with no diagnostic at all, so copy the runtime DLLs beside your .exe when you ship.

Asset filenames now carry the version. The directory inside each archive does not (starling-sdk-macos-arm64/) — that is what starling-create keys its cache by, so a cache entry is "the SDK for this platform" rather than one directory per version.

All three bundles were verified from these artifacts rather than from the tree: unpacked on a clean path, depended on by path, built with the engine-out environment variables unset, then an example run and looked at. And the strongest check available — the Starling Terminal builds for all three platforms are assembled against these bundles, not against a private tree.

Verify your download against SHA256SUMS.