// the take
A VT100/xterm terminal emulator engine for Swift, with ready-made AppKit and UIKit views plus a headless/WASM core you can embed anywhere else. It's for anyone building a terminal UI, SSH client, or multiplexer on Apple platforms (or in the browser) who doesn't want to write a parser and renderer from scratch — several shipped SSH apps (Secure Shellfish, La Terminal, CodeEdit) already use it in production.
Correctness is taken seriously: it runs against the esctest compliance suite, has a dedicated fuzzer, and even pulls in Ghostty's fuzz corpus as regression fixtures — rare for a terminal emulator outside the big native ones. The BiDi implementation is a full, spec-level build of the terminal-wg recommendation (contextual Arabic shaping, lam-alef ligatures, bracket mirroring, all six presentation modes), not a bolt-on. One engine backs AppKit, UIKit, a Metal GPU renderer, a headless mode, and a WebAssembly build, so you're not maintaining parallel terminal logic per platform. Graphics support is unusually broad for a library this size — Sixel, Kitty, and iTerm2 protocols all work, not just one.
No SSH support in the core on purpose — you're on your own wiring up swift-nio-ssh or similar, which is real integration work for the most common use case (remote terminal). It's effectively a single-maintainer project (Miguel de Icaza) with a thin bus-factor; that's fine for now given the commit cadence, but worth knowing before building something you can't walk away from. The 2.0 rewrite was a breaking API change from 1.x, so this project's API surface isn't guaranteed stable across majors — budget migration time if you upgrade later. WASM, Embedded Swift, and the Metal renderer are newer additions layered onto an Apple-views-first codebase, so they're less battle-tested in production than the AppKit/UIKit paths that ship in real apps today.
We read the README, the directory tree and a key source file in October 2026. Nobody pays to be listed. How we judge →