Wgpu on Man-You

The most useless way to port a macOS app

Tue, 24 Mar 2026 09:30:00 +0100

I grew up fascinated by projects like GNUStep, Haiku, Etoile, Wine, and ReactOS. Engineering feats, all of them. They reverse-engineer or reimplement entire operating system APIs so that software written for one platform can run on another. And they almost always end up in the same place: impressive technically, starved for contributors, forever chasing a moving target they can never quite catch.

I never liked the state of the Linux desktop either. Not because it’s bad per se, but because it’s fragmented. A KDE app on GNOME looks alien. Firefox rolls its own everything. GTK and Qt will never agree on anything. Every toolkit draws its own widgets, manages its own text rendering, handles its own accessibility story. The result is a desktop that feels like a coalition of independent projects rather than a coherent system.

This project is not going to fix any of that. But it’s an interesting story about how a combination of prior work, Apple open-sourcing key components, and an AI pair programmer led me down a rabbit hole I didn’t plan to enter.

The prior art that made this possible

I’ve been working with wgpu (Rust’s WebGPU implementation) for a while now, building a map renderer for Woosmap. That project taught me the fundamentals: how to manage GPU pipelines, how to do instanced rendering, how to deal with text atlases and glyph rasterization, how to bridge Rust and Swift through UniFFI.

On the Swift side, I had two apps: Tunes, a music player, and Leela, an internal management tool for Woosmap services. Both are SwiftUI apps, both depend on Apple’s frameworks in the usual way.

So one evening, half-curious and half-joking, I fed Claude the source of those projects alongside some context about GNUStep and friends, and typed:

“What would it take to make Tunes build and run on Linux?”

And then things got out of control.

What Claude came back with

The answer was, predictably, “a lot.” But the interesting part was the breakdown. SwiftUI is the main dependency, and SwiftUI is closed-source. But Swift itself is open-source. Swift Foundation is open-source. The Swift Package Manager works on Linux. So the gap is really:

A SwiftUI implementation (the view hierarchy, state management, layout engine, modifiers)
Some AppKit shims (NSColor, NSAppearance, the bits that SwiftUI still leans on)
A rendering backend that isn’t Core Animation or Metal
A compositor to manage windows, menus, and the desktop chrome

Instead of stopping at “that’s insane, don’t do it,” I kept going. Claude kept going. We started building.

Architecture

The project (codenamed Clone) splits pretty naturally along a language boundary.

Rust does what Rust is good at: GPU work. A wgpu renderer with pipelines for rectangles, rounded rects (SDF-based, because I can’t stop using SDFs apparently), shadows, text via a glyph atlas, and wallpapers. It also runs the window compositor through winit.

Swift does what Swift is good at: UI. A from-scratch SwiftUI implementation (about 50 View types, @State/@Binding/@Environment, ViewBuilder, layout, modifiers), the whole declarative stack. Plus enough AppKit shims to keep real apps happy, a SwiftData reimplementation backed by SQLite, and an IPC protocol over Unix sockets.

UniFFI bridges the two. Each frame, Rust asks Swift for render commands, Swift resolves the view tree into a flat list of positioned primitives, and Rust batches them into instanced GPU draws. It’s the same bridge I use in the map renderer, so at least that part wasn’t new territory.

graph LR
A["App.body"] --> B["ViewBuilder"] --> C["_resolve()"] --> D["Layout"]
D --> E["CommandFlattener"] --> F["IPC
CGFloat → Float"] --> G["Rust batcher"] --> H["wgpu draws"]
style A fill:#c4a7e7,stroke:#6e6a86,color:#191724
style B fill:#c4a7e7,stroke:#6e6a86,color:#191724
style C fill:#c4a7e7,stroke:#6e6a86,color:#191724
style D fill:#c4a7e7,stroke:#6e6a86,color:#191724
style E fill:#f6c177,stroke:#6e6a86,color:#191724
style F fill:#f6c177,stroke:#6e6a86,color:#191724
style G fill:#9ccfd8,stroke:#6e6a86,color:#191724
style H fill:#9ccfd8,stroke:#6e6a86,color:#191724

First signs of life

The moment I’ll remember is the grey rectangle. “Clone Desktop” in the center, a dock at the bottom with colored squares. I’d been at it for hours, wrestling with UniFFI bindings and layout math, and suddenly there it was: pixels on screen, drawn by Swift code, pushed through a Rust GPU backend, on something that was decidedly not macOS.

Day one: a grey box, a label, and a dock. It's not much, but it compiles and renders.

Settings and Finder

Once the basic views worked (stacks, text, lists, navigation), I needed something real to throw at them. Settings was a natural first target: sidebars, forms, toggles, text fields, the kind of layout variety that breaks things fast. Finder came next because browsing a directory with List and ForEach is such a fundamental SwiftUI pattern that if it didn’t work, nothing would.

Settings showing Wi-Fi preferences alongside Finder browsing the home directory. Both are SwiftUI apps running through Clone's stack.

Dark mode just kind of happened. Once I shimmed NSAppearance and implemented the semantic color system (Color.primary, .secondary, the system grays), flipping between light and dark was a toggle. A small thing, but unreasonably satisfying: it made the whole experiment feel like a real desktop for the first time.

The same Settings app in light mode. Appearance switching works through the reimplemented NSAppearance and Color system.

Tunes

This was the whole point, remember? “What would it take to make Tunes build and run on Linux?” Well, it builds. The login sheet renders inside the app window rather than as a separate NSPanel (a compromise, but not a terrible one), and the SwiftUI code is essentially unchanged. TextField, SecureField, Toggle, Button, Link: they all resolve and render. Same source, different universe.

Tunes running its login flow through Clone. The sheet renders in-window rather than as a separate panel, one of many compromises.

Leela

Leela is a management dashboard for Woosmap services: tabs, lists, nested navigation, version selectors, deploy queues. Most of the UI is driven by API responses, so it hammers ForEach with dynamic data, @StateObject, and conditional rendering. If Settings was a stroll through the park, Leela was a stress test.

Leela's services view running through Clone. Tabs, lists, version badges, sidebar navigation, all SwiftUI, all reimplemented.

I won’t pretend it was smooth. Getting here meant implementing a surprising amount of SwiftUI’s surface area. The state management system alone (StateGraph, scoped identity for ForEach, call-index disambiguation) went through several iterations where everything would render once and then silently stop updating. The kind of bug where you stare at a diff for an hour before realizing a closure captured a copy instead of a reference.

Under the hood

Text rendering

Text goes through cosmic-text for shaping, then gets rasterized into a 4096x4096 glyph atlas (single-channel, R8). Each glyph is cached and rendered as an instanced GPU quad. Fonts are bundled: Inter for UI text, Phosphor for icons.

This is almost certainly not how Apple does it. A real system would share GPU textures between the compositor and app, or pull from a system font cache. But it works, and there’s a special joy in watching a glyph atlas fill up character by character as the UI renders for the first time.

Layout

I reverse-engineered SwiftUI’s layout by reading objc.io’s thinking-in-swiftui and a lot of trial and error. The model: parents propose a size to children, children report back what they need, parents position them. Sounds simple until ZStack enters the picture: nil-sized views from .background() modifiers would expand to fill constraints and eat space from real siblings. That one took a while.

ScrollView was another head-scratcher: it fills its proposed size but lays out content unbounded in the scroll axis. Getting that inversion right, where the container constrains in one direction and is infinite in the other, broke my mental model twice before clicking.

IPC

Each app is a separate process. The compositor (CloneDesktop) runs the Rust event loop and manages surfaces. Apps connect over a Unix socket at /tmp/clone-compositor.sock and exchange length-prefixed JSON messages. There’s an annoying CGFloat-to-Float conversion at the wire boundary: Swift thinks in 64-bit coordinates, the GPU thinks in f32, and someone has to reconcile that at the border.

The `ycodebuild` trick

This is probably my favorite hack in the project. To compile an existing macOS app against Clone instead of Apple’s frameworks, ycodebuild generates a shadow SPM package that maps import SwiftUI to Clone’s SwiftUI, import AppKit to Clone’s shims, and so on. The app source code doesn’t change at all: you just build against a different package graph, and the compiled binary talks to the compositor over the socket. The same .swift file, two completely different platforms.

Honest assessment

I should be upfront about the gap between “it renders” and “it works.”

Animations are mostly stubbed. Accessibility is nonexistent. The compositor redraws every surface every frame like it’s 1997. There are // TODO: implement scattered across the codebase where AppKit APIs return no-ops and hope nobody notices. Sheets render in-window because I never built the panel system. The glyph atlas will fall over the moment someone opens a CJK document.

And (this is the awkward part) it doesn’t actually run on Linux yet. The whole premise was “what would it take,” and the answer turned out to include some Apple framework dependencies I haven’t replaced with their open-source equivalents. It’s doable. It’s just not done.

But here’s the thing that caught me off guard. The time from that initial Claude prompt to a state where Tunes and Leela compile and render recognizable UI was hours, not weeks. Not autonomous AI magic (plenty of manual fixes and architectural decisions along the way) but Claude carried an enormous amount of boilerplate: generating 50 View type stubs, wiring up modifier chains, implementing the state graph, setting up IPC. The kind of work that would’ve taken me days of tedious typing, compressed into a conversation.

Why this matters (a little)

Apple open-sourcing Swift and Foundation was a bigger deal than most people realize. Not because anyone’s going to ship a SwiftUI app on Linux tomorrow, but because it lowered the floor for experiments like this from “completely impossible” to “merely impractical.”

The projects I admired growing up (GNUStep, Haiku, Wine) were built by small teams reverse-engineering closed systems over years. The combination of open-source language infrastructure and AI assistance compresses that timeline dramatically. Not to a point where it’s practical or production-ready, but to a point where a single person can explore the shape of the problem in a weekend.

That’s the real takeaway. Not “I ported macOS to Linux.” I didn’t. But I went from a throwaway prompt to colored boxes on screen running real SwiftUI app code, and that felt like something worth writing about.

What’s next

Honestly? Probably nothing. The project scratched a twenty-year itch. But I know myself, and I know there’s a Kawase blur pipeline sitting unused in the renderer that’s going to call my name at 11pm some Tuesday. If I do keep going:

Per-window offscreen textures: the compositor shouldn’t redraw everything every frame, that’s embarrassing
Glassmorphism / backdrop blur: because what’s the point of reimplementing macOS if you can’t have the frosted glass
Actually running on Linux: the whole original premise, still unfinished
Shared GPU textures: how a real compositor would work, instead of copying pixels through a socket like an animal

Or maybe it stays as a weekend experiment and a blog post. Either way, the kid who thought GNUStep was the coolest thing ever is pretty happy right now.

Building a GPU map renderer from scratch

Tue, 10 Feb 2026 09:00:00 +0200

Building a vector map renderer in Rust with wgpu. From “everything renders as points” to a full style-driven renderer running on desktop, iOS, and the browser.

Why

We built our maps stack on top of Mapbox GL: the JS SDK, then native SDKs on the C++ core.

For static maps we wrapped the C++ SDK in a Python library (maparazzo). It worked but the C++ renderer leaked memory. OpenGL contexts kept state around after objects were destroyed. We tried pooling Map instances, reusing GL contexts. It helped but never fully solved it.

I wanted to understand every layer of the stack. What if we built a renderer from scratch, something we fully own, no inherited complexity from a massive C++ codebase?

Rust + wgpu seemed right. wgpu abstracts over Metal/Vulkan/DX12/WebGPU so you get native + browser from one codebase. Rust gives you memory safety without a GC. No more mystery leaks.

First pixels

Started from the wgpu-triangle example: a bare-bones triangle on screen. Built the stem by hand: tile fetching, MVT decoding, basic projection. From there I heavily leveraged Claude Code to help push through the harder parts and get it to where it is now.

Everything in one file. main.rs at 1,500 lines: MVT decoder, protobuf parser, renderer, tile fetching, all of it.

The MVT decoder is hand-rolled. No prost, no generated code. Protobuf is simple enough at the wire level: varints, length-delimited fields. The tile format uses a local coordinate grid (4096x4096 per tile) with delta-encoded geometry commands.

First render: every feature drawn as points. Polygons, lines, everything, just dots on screen. But dots in the right places.

Making it a real map

Extracted modules one by one. mvt.rs for tile decoding, renderer.rs for GPU work, tile_loader.rs for fetching, tile_coords.rs for slippy map math.

Added earcutr for polygon triangulation: it converts arbitrary polygons with holes into triangles the GPU can draw. First tessellation attempt produced spikes everywhere. The MVT spec requires rings to be closed but some tiles had implicit closure. Two-pass decode: first pass collects keys/values/feature ranges, second pass builds features with proper ring closing.

Background tile loading with worker threads and mpsc channels. Scroll zoom, mouse pan. Viewport buffer zone to pre-load surrounding tiles so panning feels instant.

Tessellation cache keyed by (TileCoord, layer_index, feature_index): earcut is expensive, no need to redo it when the camera moves.

Moving projection to the GPU

The big architectural decision. Originally the CPU converted every vertex from lon/lat to screen pixels. Camera move = rebuild all vertices = slow.

Flipped it: vertices store world lon/lat, the GPU shader does Web Mercator projection. Camera moves only update a 64-byte uniform buffer. Vertex data stays untouched.

center_mercator, scale, rotation, viewport_scale, aspect, viewport_size

This means mark_camera_dirty() for pan/zoom (cheap uniform upload), mark_geometry_dirty() only when tiles arrive or leave. Night and day difference for interactivity.

Style-driven rendering

A map renderer without style support is just a polygon viewer. Built an expression engine and style evaluator.

The expression engine handles the Mapbox style spec: get, has, match, case, interpolate, step, let/var, coalesce, arithmetic, string ops, comparisons. let/var was critical: Woosmap styles use variable bindings for i18n name resolution.

Filter compilation: both legacy ["==", "key", val] and modern ["==", ["get","key"], val] syntax.

The key insight for z-ordering: iterate style layers, not MVT layers. The style defines the draw order. For each style layer, find matching features across all tiles.

Background color comes straight from the style: just set the wgpu clear color.

Paris at different zoom levels, same style, same renderer, z4 to z16:



z4, country level	z8, region level

z12, city level	z16, street level

Lines

Lines in a GPU renderer are not trivial. A “line” on screen is actually a quad (two triangles) for each segment, with normals perpendicular to the direction. Line joins at vertices need special treatment.

Implemented miter, bevel, and round joins. Miter joins can spike to infinity at sharp angles, so clamp with a miter limit and fall back to bevel. Round joins emit a fan of triangles.

Line normals computed in Mercator space, not screen space, because of the GPU projection design. The shader transforms them correctly.

Icons and sprites

Sprite atlas: load {url}.json (metadata) + {url}.png (texture). Each icon is a region in the atlas with UV coordinates.

SDF (Signed Distance Field) rendering in the fragment shader. One shader handles both SDF sprites and regular RGBA sprites: the is_sdf field on each vertex switches behavior. SDF gives you clean scaling and halos at any size from a single texture.

Icon quads: 4 vertices + 6 indices per point. Screen-aligned: the anchor position projects through the map transform but pixel offsets stay fixed.

@2x sprite support for Retina: load the high-res atlas, halve the pixel sizes.

Text

Text was the biggest single feature. PBF glyph format (same as Mapbox), shelf-packed texture atlas, SDF rendering reusing the icon shader.

GlyphAtlas dynamically grows (1024x1024 initial, doubles when full). SDF distance stored in alpha channel. The glyph shader is literally the icon shader: is_sdf = 2.0 + halo_buff triggers PBF glyph mode with the correct SDF thresholds.

Text shaping is 1:1 codepoint-to-glyph. No GSUB/GPOS, no complex script support yet. Works for Latin, CJK, Cyrillic. Arabic and Thai would need a real shaper like rustybuzz.

Word wrapping, text-anchor (9 positions), text-offset, text-variable-anchor with collision retry, text-radial-offset, text-justify.

Collision detection

Without collision detection, labels pile on top of each other. Built a grid-based system.

Labels grouped by feature: icon + text for the same feature are placed together (all-or-nothing). Groups sorted by (layer_index, symbol-sort-key). Grid cells are checked, if occupied the label gets rejected and fades out.

Variable anchor retry: if a label’s primary anchor collides, try alternatives. Pre-compute screen positions for each anchor variant, test them in order. Phase 1: collect decisions. Phase 2: apply vertex shifts. Two phases to avoid borrow conflicts.

A tour of European cities, all rendered with the same pipeline:



Paris	London	Barcelona

Amsterdam	Berlin	Rome

Vienna	Prague	Budapest

Stockholm	Istanbul	Athens

Lisbon	Copenhagen	Helsinki

Oslo

Performance

Event-driven loop with ControlFlow::Wait. No busy polling. EventLoopProxy waker: worker threads signal the event loop when tiles arrive.

Extract debounce: during active zoom/pan (100ms window), skip full geometry extraction, just update camera uniforms. Once input stops, run the deferred extract. New tile arrivals always trigger extract immediately: you want to see them.

Zoom style patches: instead of re-extracting everything when zoom changes (colors and sizes are zoom-dependent), patch the extracted vertex data in-place. Rewrites only the color/opacity/width fields.

Time-sliced extraction: spread heavy work across multiple frames so the renderer doesn’t stall.

Dependencies optimized in debug builds: [profile.dev.package."*"] opt-level = 2.

Multi-platform

macOS / iOS with UniFFI

UniFFI generates Swift bindings from Rust. MapEngine wraps wgpu in a Mutex, exposes methods like draw_frame(), set_center(), set_zoom().

The Metal surface is created from a raw CAMetalLayer pointer. MSAA disabled in the FFI path because MTKView’s MSAA resolve triggers a size mismatch with wgpu. sRGB correction handled by a uniform flag: fragment shaders apply sRGB-to-linear when rendering to MTKView’s sRGB surface.

HttpClientDelegate callback interface: Swift injects a URLSession-backed implementation so network requests go through the platform’s native stack.

xcframework build: aarch64-apple-darwin, x86_64-apple-darwin, aarch64-apple-ios, aarch64-apple-ios-sim.

Browser with WASM

wasm32-unknown-unknown target, wasm-bindgen for the JS interface. Tile loading uses browser fetch() via web_sys. No threads in WASM so tile extraction is sequential (10-30 tiles is fine without parallelism).

Style/sprite loading is async in the WASM path (browser fetch) vs sync on native (ureq). The renderer has platform-agnostic setters: apply_style_data(), set_sprite_atlas().

web-time crate replaces std::time::Instant everywhere: re-exports std on native, performance.now() on WASM.

Globe

Optional 3D sphere projection at low zoom (toggle with G key). The shader branches on a globe_mix uniform: above 0.5 it projects lon/lat onto a unit sphere, rotated by center latitude and map rotation.

Back-face discard in the fragment shader: globe_rz < 0.0 hides the back of the sphere. No depth buffer needed.

Polygon subdivision for the globe: edges longer than 5 degrees get split recursively. Conforming subdivision: all edges of a triangle get split (not just the longest) so adjacent triangles agree on shared edge vertices. No T-junction cracks.

Google Maps Styler

A declarative styling engine that applies Google Maps-style JSON rules to modify layer colors. HSL transforms: hue, saturation, lightness, invert, gamma. Delta-based: rules shift colors rather than setting absolute values.

Hierarchical feature type matching with a tree structure. "all" walks the entire tree, "road.highway" matches just highway layers.

POI expansion: the styler takes a single POI layer with class metadata and expands enabled classes into individual layers, each with its own filter and icon.

Where it stands

This is not done. It’s not a replacement for Mapbox GL Native, not even close.

233 tests. The basics work: fill, line, background, symbol layers with icons and text. Expressions, collision detection, variable anchor, text wrapping, text justification. Runs on macOS, iOS, and the browser. Globe projection at low zoom.

What’s missing or broken:

Text shaping is naive 1:1 codepoint-to-glyph. Arabic, Thai, Burmese, anything that needs ligatures or reordering doesn’t work. Need rustybuzz or equivalent.
Line rendering has no dashes, no gradients, no line-cap styles beyond basic round.
Symbol placement along lines is basic. No label curving along the road, no smooth rotation interpolation.
Collision detection is coarse. The grid works but it’s not as smart as Mapbox’s: no cross-tile collision, no viewport-edge handling for partially visible labels.
Raster layers not supported at all. No hillshade, no satellite imagery compositing.
Performance is acceptable for interactive use but extraction is still heavier than it should be. Mapbox GL Native has had years of profiling and optimization. We haven’t.
Fill extrusion (3D buildings) not implemented.
Rotation mostly works but some label placement breaks at non-zero bearing.
Expression coverage is incomplete, missing format, image, number-format, to-color and several type conversion operators.

About 15,000 lines of Rust. No C++ dependency. No OpenGL. The foundation is there, the details are not.