Less between a thought and a command.
Open a shell. Run a command. Start a project. Spend an afternoon in a text-based tool. These are small, familiar actions, but the terminal sits in the middle of all of them.
Lean Term is being built around that everyday loop. Its purpose is a fast, lean terminal for macOS with a clear interface that feels good to use.
That means paying attention to the whole experience: when typed input becomes visible, how output behaves under load, how quickly a shell is ready, and what the app asks of your Mac while you work.
Three priorities, in order.
Speed comes first.
Typing and terminal responsiveness lead the decisions. Startup matters too. We want the app to keep up with your hands, your shell, and the tools you run inside it.
Keep the footprint small.
Memory and CPU use matter even when the terminal is sitting quietly. We will measure resource use at idle and after sustained work, alongside responsiveness.
Make it lovely to use.
Performance belongs in a clean, usable interface. Readable type, considered colors, and understandable controls are part of the product, from the start.
These are design priorities. Published performance claims will need measurements from an identified Lean Term build. Our benchmark guide explains the checks and the results we plan to publish.
A native start for the first version.
Lean Term’s v1 stack is mostly Swift, built around existing native components:
- Swift + AppKit for the Mac interface and app behavior.
- SwiftTerm for the terminal engine, terminal view, and local shell/process connection through its PTY support.
- CoreGraphics + CoreText for the initial drawing path, through SwiftTerm.
SwiftTerm’s CoreGraphics view gave encouraging typing-response results in both local prototype passes. Reusing its engine, view, and shell connection lets us focus on Lean Term’s clean interface while keeping one primary language and toolchain.
Those tests informed the first version’s implementation choice. They measured development fixtures; the released app’s own performance report will be published once its measurements are ready. CoreGraphics and CoreText describe the drawing APIs we are using; macOS still manages the display pipeline.
Why not Rust yet?
We have not benchmarked a Rust implementation, so these tests do not establish a Swift-versus-Rust speed ranking.
A Rust engine would add another toolchain, a bridge between Swift and Rust, and more integration work. The current prototype results support a practical starting point with the reusable Swift component; they have not shown a reason to add that work for v1.
Rust remains an option if future profiling identifies a specific bottleneck and demonstrates a concrete benefit. The priorities stay the same: responsive input, a small footprint, and a beautiful, usable Mac interface.
Free and open source.
Lean Term is being developed as a free, open-source app for everyone. The public source repository is on GitHub, so you can inspect the code and follow the project. A signed, notarized app download is also available for Apple silicon Macs running macOS 26 or later.
We are starting with macOS and a focused terminal experience. See downloads and installation for requirements and the current release.
An early release, with more to come.
An early release of Lean Term is available. The terminal on the home page remains an interactive design concept; its appearance may differ from the app.
We need our own measured performance numbers, too. Those will be published once measurements of the released app are ready. Early experiments help development; the public report must identify the actual app build being measured.
See downloads and release notes for the current release status.