I wrote a Mac code editor in Rust with its own Metal UI toolkit

Sujit Baruwal — Tue, 06 Oct 2026 13:10:45 +0000

Every code editor I used daily was a web browser in a trench coat. VS Code,
Zed's predecessors, all of them: Chromium or a web view somewhere in the stack,
carrying the memory footprint and the uncanny almost-native feel. I wanted an
editor that feels like it belongs on a Mac — native menus, native dialogs, the
shortcuts my fingers already know — so I wrote one. In Rust. With its own GPU
UI toolkit on Metal.

It's called Orbvane. It's open source
(MIT/Apache-2.0), signed and notarized, and you can install it with:

brew install --cask sbaruwal/tap/orbvane

This post is about the technical decisions that made it possible — and the ones
that bit me.

Why not Electron (or Tauri, or GPUI)

The short version: control. A web view decides your memory floor, your input
latency, and how "native" your app can ever feel. I wanted keystrokes that land
in under a millisecond in a million-line file, 120Hz scrolling, and a UI that
respects macOS conventions instead of approximating them.

The longer version: I enjoy suffering, apparently. Writing your own UI toolkit
means writing your own text layout, focus management, menus, dialogs, drag and
drop — everything a platform or framework normally hands you. The bill comes
due in the least glamorous places. More on that below.

The architecture

The stack, bottom to top:

Windowing: winit. It handles the platform layer and, importantly, the NSTextInputClient bridging on macOS that makes input methods work.
Rendering: wgpu on Metal, with our own retained-mode UI toolkit on top. Retained, not immediate-mode: the toolkit keeps a scene of what's on screen and re-renders only what changed (dirty-rect tracking). Immediate mode is lovely to write, but you re-pay the layout cost every frame. Caching glyphs and layout in RAM is what makes 120Hz scroll possible — RAM usage isn't the enemy, redoing work is.
Text: cosmic-text for shaping (it handles ligatures, complex scripts, emoji), over our own buffer with rope-like structure for large files.
Languages: tree-sitter for highlighting (36 grammars), and real language servers over LSP for everything smart — diagnostics, completion, rename, go-to-definition. The editor doesn't reimplement what servers already do.
Debugging: DAP. lldb-dap for Rust/C/C++/Swift, debugpy for Python, Delve for Go, and our own adapter for Node.
Terminal: our own xterm-compatible emulator with split panes.
AI: the assistant talks to the CLIs you already have (claude, codex) instead of shipping another API integration.

The principle throughout: own the things that define the feel (rendering, text,
input), rent the things that are protocols (LSP, DAP, MCP-shaped tools).

The bug that taught me the most

Shortly after launch, someone asked on X how the custom GPU toolkit handles CJK
IME input — "that's usually what breaks first in custom-drawn editors." They
were right, and it was broken: winit was emitting the IME preedit/commit
events, and nothing in the editor handled them. CJK composition simply didn't
work.

The fix shipped the same day in 0.3.2: handle the preedit events, render the
marked text with an underline at the caret, position the candidate window at
the caret, and give CJK/emoji their proper two-column width in the editor.

The lesson generalizes: in a custom-drawn editor, text input is the feature.
Not rendering, not themes — input. IME, dead keys, bidirectional text,
accessibility APIs. These are the unglamorous systems that decide whether your
editor works for everyone or just for people who type ASCII. I now treat every
one of them as load-bearing.

What's genuinely hard

Honesty section. Things that are done, things that aren't:

Done: fast startup, huge files, LSP/DAP/terminal/git/tests/extensions, AI assistant, IME with inline composition, no telemetry.
Not done: accessibility (VoiceOver) — custom GPU UI is invisible to assistive tech until you implement the macOS accessibility APIs, and that's real work touching the whole UI tree. This is next on my list after input.
Untested: bidirectional text. Shaping handles it; caret movement in mixed-direction text is where custom editors break, and I haven't verified ours yet.
By design, missing: remote dev over SSH, notebooks, running extension JavaScript. Some of these will come; some are deliberate scope cuts.

Try it, break it, tell me