Nimble Commander and the case for a dual-pane file manager on macOS

Two panes, one keyboard-first design

Nimble Commander is a dual-pane file manager for macOS. The dual-pane layout is the classic arrangement where one directory sits on the left, another on the right, and the space between them is the working area, so copying and moving becomes a matter of selecting a source and a destination without a separate dialog.

The stated design intent is specific. The project describes itself as free, focused on speed, keyboard-based navigation and flexibility, and it says the aim is to blend the experience of classic file managers from the 80s and 90s with the modern look of a Mac. That combination is the reason to look at it, and it is also where the trade-off sits. A keyboard-driven interface is faster for someone who learns the shortcuts and slower for everyone else, so the appeal depends on whether the person installing it is already comfortable in that model.

The repository topics list adds two hints about the scope. terminal-emulator means it is not only a file browser, and vfs means file access goes through an abstraction layer rather than straight to the POSIX calls, which is how a virtual file system feature can exist alongside ordinary local directories.

Three install channels, and they are not the same build

The application is distributed through three separate routes, and the distinction between them matters.

The simplest is Homebrew. The getting started section gives the install as one line, in the project's own words:

Install via Homebrew: `brew install nimble-commander`.  

The second is a direct disk image download of the current release, hosted at the project's own download address, and the third is the Mac App Store listing, which points at the Files app entry. A user on a Mac can therefore treat it as a normal App Store application, update it from there, and never touch a build.

The third channel is the nightly build, and it is the one with a catch. Nightly artifacts are produced by a GitHub Actions workflow and are downloaded from the Artifacts section of the most recent integration, which requires a GitHub account. The workflow is a separate one from the build and test workflow that carries the repository's status badge, so nightly and CI are distinct pipelines rather than one process.

That distinction is worth understanding before you install. The Homebrew cask, the disk image and the App Store version are release artifacts, while the nightly is a continuous build with no version number attached, and a nightly is the only way to see changes that have not yet been tagged.

The release list is short and the gap between tags is long

The published versions are v1.6.1 on 2024-07-23, v1.7.0 on 2024-12-18 and v1.8.0 on 2025-12-19. That is roughly five months between the first two tags and then a full year to the third, which is a slow cadence for a desktop application and tells you something about how the project is run.

The last push to the repository was on 2026-10-18, so the code is being worked on even though the newest listed tag is v1.8.0 from 2025-12-19. The gap between the two is the interesting part: development continues on main while the release line moves at a slower pace, and the nightly build is the mechanism that carries intermediate work to people who want it.

Two documentation files keep the history legible. WHATS_NEW.md holds the details for each released version, and past releases are hosted in a separate repository, nimble-commander-releases, so the main repository does not accumulate binaries. For a user deciding whether to install from Homebrew or from a nightly artifact, the changelog is the place to find out what actually changed between the two.

A C++ codebase with its own third-party directory

The source layout is visible at the top level of the repository. Source/ holds the application code, 3rd_Party/ holds bundled third-party code, Scripts/ holds the supporting scripts, and Docs/ holds the user and build documentation. The project is primarily C++ with Cocoa for the macOS interface, and the 3rd_Party directory is a signal worth noticing because it means some dependencies are vendored into the tree rather than resolved by a package manager.

Vendoring has a purpose. For an application that has to build a signed Mac binary, pinning third-party sources in the repository removes a moving target from the release build, and it lets the author patch a dependency when upstream does not move fast enough. The cost is a merge burden when updating those libraries and a larger tree to review.

The build system details are not in the short project description at all. They are delegated to Docs/Building.md, which the project points to for build instructions and an overview of the source code, so anyone expecting to compile from source needs to read that document first rather than guessing at the layout. The user guide is a separate file, Docs/Help.md, and CONTRIBUTING.md covers how to report bugs and submit changes.

GPL-3.0 is the licence that decides the adoption question

The source is distributed under the GNU General Public License version 3, copyright Michael Kazakov. The LICENSE.md file sits at the repository root next to the project description, and the licence identifier in the description is GPL-3.0.

For an end user installing the application on their own Mac, that licence creates no obstacle. The copyleft obligation attaches to distributing the code, not to running it, and the Homebrew cask, the disk image and the App Store build are all ordinary ways to obtain a binary.

Where it does matter is if you intend to embed the code, fork it for an internal product, or ship a modified build, and equally if you are a company that has a policy against GPL components in the stack. Those are questions for your own legal review rather than a conclusion to draw from a licence file, but the direction of travel is worth knowing early rather than at release time. The presence of a CODE_OF_CONDUCT.md alongside the licence indicates the project has the usual governance paperwork for a project of this size.

What Nimble Commander is not for

The realistic mismatch is a team that wants to script file operations in a reproducible way. A dual-pane manager is an interactive tool, and the project documentation points to a user guide and a changelog rather than to a command line interface, a configuration schema or an API. If your need is unattended file movement across machines with logging, this is the wrong category of tool, and the presence of a terminal emulator inside the app is about the user working manually, not about the application being driven by a script.

The second mismatch is the platform. This is a macOS application with a Cocoa interface, so it does not run on Linux or Windows, and even the build instructions are specific to the Mac toolchain.

The third is expectations about release frequency. A project with roughly yearly tags and a nightly build channel suits someone who wants the current state of main, but it is a different maintenance profile from a product that ships user-visible changes every few weeks. The nightly build is the answer there, and it does require a GitHub account to fetch the artifacts, which is a small but real friction for a team that would otherwise not have one.

A single developer project with a large, careful codebase

The copyright line names one person, and the repository structure reflects that. There is a single author and maintainer, a CHANGELOG-style file, a user guide, a building guide and a contribution guide, with the code in one Source/ tree. The pattern is a well-organised single-maintainer project rather than a team operation with a roadmap document.

For a user that is reassuring, because the application has been in continuous existence since the copyright line begins at 2013 and continues into 2026, and the version numbers have reached 1.8.0. The Mac App Store presence, the Homebrew cask and the nightly artifacts all point to a project that has kept the packaging side of shipping in working order over that span, which is harder than it sounds for a desktop utility with no company behind it.

The home page is at magnumbytes.com, and the same site hosts the release downloads. The daily-driver case for this application is a person who moves files between local and remote locations, organizes large directory trees, and wants to do it without reaching for the mouse, and everything else about the project, from the vfs layer to the terminal emulator, exists in service of that.

Editorial conclusion

Nimble Commander fits a macOS user who works with files in a keyboard-driven way and wants two panes, a terminal emulator and a virtual file system layer in one GPL-3.0 application that installs with brew install nimble-commander. It does not fit a team that needs a permissive licence, because GPL-3.0 obligations travel with any redistribution of the code, and it does not fit someone who wants a fast-moving release stream, since the newest listed tag is v1.8.0 from 2025-12-19 while the last push to the repository was on 2026-10-18. Before committing to it, read Docs/Help.md for the command set and Docs/Building.md for the source layout, and decide whether the nightly build workflow, which needs a GitHub account to pull artifacts, fits your release process.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. mikekazakov/nimble-commander on GitHub
3. Project website
4. README
5. Releases