About half my working day happens over SSH: reading logs, deploying releases, and investigating production issues. I spend the other half building tools to make the first half shorter.
I have spent a lot of time with almost every kind of SSH setup on a Mac: the built-in terminal and ssh command, general-purpose cross-platform terminals, browser extensions, and several established clients. They all connect to servers. After eight hours a day, the differences show up in two places: whether the interface feels like a Mac app, and whether connections are treated as first-class objects.
Where cross-platform tools can fall short
Cross-platform terminals have to serve every operating system, which can leave each one with an experience somewhere in the middle:
- Following the system’s light or dark appearance, rendering fonts, and matching keyboard conventions rarely all feel quite right.
- Connection settings, tabs, and splits can follow separate mental models that do not fit the system’s window management.
- Where passwords are stored and how to migrate them are often the least clear parts.
- Fixes depend on upstream releases; waiting for a cross-platform framework to address a Mac-specific edge case can take a long time.
Each issue looks small on its own. Together, they can mean extra minutes every day and a persistent feeling of being one layer removed from the system.
What native actually means
For Docklark, native means a specific set of commitments:
- Run directly on Apple Silicon, without translation.
- Switch between light, dark, and system appearance, with system changes reflected in the app.
- Follow macOS menu and keyboard conventions, with the compact toolbar and system menus using the same actions.
- Entrust connection passwords to macOS Keychain rather than inventing an encrypted file format.
- Make windows, tabs, and splits behave consistently with other Mac apps.
Connections as first-class objects
The biggest difference between a native SSH client and a terminal that happens to support SSH is that connections are managed as objects:
- Nested connection folders, favorites, sorting, and bulk actions mean a growing server list does not have to live in your memory.
- Timeouts, keepalives, compression, and local, remote, and dynamic port forwarding are properties of a connection.
- SFTP and resource monitoring reuse the authenticated SSH connection, without asking for the password again.
- Sessions can be duplicated, locked, and sorted by host. After disconnection, they can return to a local shell or wait for reconnection.
These capabilities need more than a terminal with a script attached: the client needs to understand the whole connection lifecycle.
The terminal should feel native too
The terminal itself has its own checklist: a global scrollback limit from 1 to 100,000 lines, live search that follows new output, visual and optional audible bells, per-connection tab colors, and seven terminal palettes with custom ANSI colors. These are not decorative extras. They shape the feel of an interface you spend eight hours looking at.
Honest limits
This article records design ideas from Docklark’s development. As of October 18, 2026, a v0.2.61 installer is publicly available on GitHub Releases. Progress in the source code does not mean every feature has been verified in that installer. Earlier versions have been tested on real devices for direct SSH, JumpServer login, and access to target servers. Broader acceptance testing is still unfinished, including transfer-speed comparisons on a real local network. I will keep writing about that progress here.
If you want an SSH client that treats a Mac as a Mac, follow Docklark’s development progress.