AeroSpace: an i3-style tiling window manager for macOS

What AeroSpace solves, and for whom

macOS ships with a window model built around free-floating windows and native Spaces. AeroSpace replaces that with a tiling window manager based on a tree paradigm, in the style of i3. Tiled windows are placed by the layout, and the user moves focus and rearranges the tree with commands. Floating windows are also supported.

The audience is narrow and specific. It is for people who already work in i3, sway or a similar tiling environment and want the same mental model on a Mac. The README lists the properties that matter to that group: fast workspace switching without animations, plain text configuration that is dotfiles friendly, a CLI-first design with manpages and shell completion, and i3-like multi-monitor handling. The project explicitly says it does not require disabling SIP, which distinguishes it from window managers that ask the user to weaken System Integrity Protection to hook into the window server.

It is not a general macOS window improvement. If you like Mission Control, Stage Manager or native Spaces, AeroSpace is not a layer on top of them; it substitutes its own workspace model, and you have to learn its commands to get anything done.

The tree paradigm and emulated virtual workspaces

Two mechanisms define how AeroSpace works. The first is the tree. Layout is a hierarchy rather than a flat list of windows: containers hold windows, and operations act on nodes in that tree. The project's documentation points to the tree paradigm as the core concept, and the current development plan describes a rewrite of the mutable double-linked core tree data structure into an immutable single-linked persistent tree. That rewrite is listed as unfinished, and the project ties two known issues to it: windows sometimes jumping to the focused workspace, and support for macOS native tabs.

The second mechanism is workspace emulation. Rather than using native macOS Spaces, AeroSpace implements its own emulation of virtual workspaces. The README gives the reason directly: the limitations of native Spaces. The practical consequence is that workspace switching happens inside AeroSpace, which is why the project can advertise switching without animations. It also means workspace behaviour is defined by AeroSpace's own rules and configuration, not by Apple's.

Multi-monitor support follows an i3-like paradigm, and the README adds a warning for that case: in a multi-monitor setup, monitors must be properly arranged, with a link to the guide section on monitor arrangement. That is a configuration precondition, not an optional nicety.

Installing AeroSpace from the Homebrew tap

The README marks Homebrew as the preferred installation route because it brings autoupdates. The cask lives in the nikitabobko/tap tap, so the install command names it explicitly:

brew install --cask nikitabobko/tap/aerospace

After that command completes, AeroSpace should appear as an installed application. The README notes that the Homebrew installation script is configured to delete the com.apple.quarantine attribute automatically, so the app should start without the warning that Apple cannot check it for malicious software. The project also states plainly that AeroSpace is not notarized, and that using it means acknowledging that. The README links to other installation options in the guide for anyone who does not want the cask.

Configuration is a TOML file. The guide publishes a default-config.toml, and the README describes configuration as plain text and dotfiles friendly. The project is CLI first, with manpages and shell completion included, so the same actions available through keybindings are reachable from a terminal. If you run more than one display, read the proper monitor arrangement section before you judge the layout behaviour.

Where AeroSpace is the wrong tool

The README labels the project a public beta and says it can be used as a daily driver, but that breaking changes should be expected until 1.0 is reached. That is the maintainer's own framing, and it should be taken literally: configuration and command behaviour are not frozen. Anyone who needs a window manager whose interface will not move under them should wait.

The second limitation is notarization. AeroSpace is not notarized, and the README explains the maintainer's position on Apple's notarization process rather than promising to comply. Homebrew works around the resulting Gatekeeper warning by removing the quarantine attribute. If your environment forbids non-notarized software, or if you install by a route that does not strip that attribute, this becomes your problem, not a bug.

There is also a known stability issue in the current tree implementation, documented as windows randomly jumping to the focused workspace, which the planned refactoring is expected to help fix. And the project does not accept issues directly: the README asks users to open a GitHub Discussion first, with a #potential-bugs channel for suspected bugs. If your workflow depends on filing a tracked issue and getting a ticket number, that process will feel wrong.

AeroSpace compared with rectangle-style snapping tools

The obvious comparison is with macOS window tools that snap or tile windows through keyboard shortcuts while leaving the native window model intact. Those tools move and resize windows; they do not own the layout. AeroSpace owns it. Its tree paradigm means the position of a window is derived from its place in a hierarchy, and rearranging means changing the tree, not dragging a rectangle to a screen half.

The difference shows up in two places. First, workspaces. A snapping tool works with the Spaces Apple provides. AeroSpace emulates its own virtual workspaces because of what the README calls the considerable limitations of native Spaces, so workspace switching and window placement are governed by AeroSpace. Second, configuration and control surface. AeroSpace is CLI first, with manpages and shell completion, and its configuration is plain text TOML. A shortcut-driven snapping tool is typically configured through a preferences window.

Neither approach subsumes the other. If you want a small improvement to how windows sit on screen and no change to how macOS itself behaves, a snapping tool is the smaller commitment. If you want a tiling model with workspaces you control and a config file you can version, AeroSpace is built for exactly that.

Maintenance, upgrade cost and the MIT licence

The repository is not archived, and the last push was on 2026-11-02. The most recent release listed is v0.21.3-Beta from 2026-07-16, following v0.21.2-Beta and v0.21.1-Beta earlier that month. The version string carries the Beta suffix, which matches the README's public beta statement.

The upgrade cost is the part to weigh. The README says breaking changes should be expected until 1.0, and the project's own 1.0 checklist includes a big refactoring of the core tree data structure. That refactoring is listed as unfinished and is tied to fixes for window jumping and native tab support. A configuration written today may need edits as those changes land. Keeping the TOML in dotfiles makes that cheaper, but it does not make it free.

AeroSpace is MIT licensed, with the licence file at LICENSE.txt in the repository root. The practical implication for most users is that the source can be read, modified and redistributed under the MIT terms. Nothing in the README suggests the licence affects the notarization situation, which is a distribution and Gatekeeper matter rather than a licensing one. This is a description of what the repository contains, not legal advice.

Editorial conclusion

AeroSpace fits macOS users who already think in i3 terms and want a plain-text, CLI-first configuration they can keep in dotfiles. It is a poor choice for anyone who needs a stable 1.0 interface, since the README states breaking changes should be expected, and for users who cannot accept a non-notarized app. Before adopting it, check the installation page for the non-Homebrew options, confirm the monitor arrangement guidance if you run several displays, and read the current default-config.toml so you know which keys and commands your setup will actually use.

Frequently asked questions

Official sources

1. License: MIT
2. nikitabobko/AeroSpace on GitHub
3. Project website
4. README
5. Releases