rift: a macOS tiling window manager that keeps Spaces separate

The macOS gap rift targets: fullscreen on one display, tiling on another

The README's motivation section is unusually direct about why the project exists. The author used Aerospace and "missed animations and the ability to use fullscreen on one display while working on the other." That second point is the concrete gap. Most macOS tiling window managers ask you to turn off "Displays have separate Spaces," because managing windows across independently spaced displays is harder than treating the whole desktop as one coordinate system. rift claims the opposite: it "works with 'Displays have separate Spaces' enabled (unlike all other major WMs)."

The audience is therefore not every macOS power user. It is someone who runs a multi-monitor setup, wants one screen fullscreen for video or a game while the other stays tiled, and does not want to restructure how macOS Spaces behave. The secondary audience is people coming from i3, sway, bspwm or niri on Linux who want a familiar layout model on a Mac. rift ships six: tiling (i3/sway-like), binary space partitioning (bspwm-like), floating, master-stack (dwm-like), scrolling columns (niri-style) and stack (accordion).

One constraint is stated plainly and is worth repeating because it drives the whole design: rift does "not require disabling SIP." That matters for anyone who has avoided yabai's scripting addition route or who administers a managed Mac where SIP cannot be turned off.

How rift is put together: private APIs, a Rust workspace and Mach port IPC

rift is a Rust project. Cargo.toml declares a workspace with three members: the root package, crates/rift-client and crates/rift-protocol. The root package is named rift-wm and produces a binary named rift. Splitting the IPC surface into its own protocol crate and a separate client crate is the structural signal that third-party integration is a first-class concern rather than an afterthought.

That integration runs over what the README calls "mach port based IPC for communicating with rift from third-party programs (sketchybar, etc)." The protocol crate is the schema; the client crate is what an external process links against. If you write a status bar plugin, you are working against crates/rift-protocol, not scraping a log file.

The window management itself sits on private, undocumented macOS APIs. The README says rift "uses private APIs reverse engineered by yabai and other projects," and the motivation section explains the preference: "I also prefer leveraging private/undocumented APIs as they tend to be more reliable (due to the OS being built on them and all the public APIs) and performant." That is a defensible engineering argument and also the project's largest structural risk. Private APIs are not covered by any compatibility promise, and the dependency list shows the surface area: objc2, objc2-app-kit with a long explicit feature list, block2, dispatchr, nix. An OS update can change behavior underneath any of them.

The repository also carries an experimental feature group in Cargo.toml (experimental = ["custom-event-loop", "disable-axuielement-destroyed"]) with its own sub-features. Treat anything behind that flag as not part of the supported path.

Installing rift and switching to a scrolling layout

The README does not contain install commands. Its quick start section points to two documentation pages instead: a quick start page and a configuration reference, both hosted at acsandmann.github.io/rift-docs. The binary produced by the workspace is named rift, and the repository ships a default configuration file, rift.default.toml, at the top level. That file is the reference for what a working config looks like.

Because the README gives no build or install steps, the honest guidance is to follow the quick start page rather than guessing at a cargo invocation. What can be confirmed from the repository is the artifact you end up with and the config file you start from:

# workspace members and binary name, from Cargo.toml
# [package] name = "rift-wm"
# [[bin]] name = "rift"
# default config shipped at the repository root: rift.default.toml

Once rift is running, the README describes two ways to drive it: a menubar icon that opens a menu for "switching workspaces, changing layouts, and accessing quick rift controls," and a CLI. Layouts can be saved and restored "from the menu bar or CLI, with reusable layouts listed from a configurable folder." So the first real use is not a keybinding you have to memorize. Open the menubar menu, pick a layout, and work from there while you learn the config.

The configuration is described as "hot reloadable." That means you can edit your TOML and see the result without restarting the window manager, which shortens the loop considerably when you are tuning animations or workspace rules. Other README-listed behaviors worth knowing before you commit: focus follows the mouse with auto raise, trackpad gestures switch to the next or previous workspace "just like native macOS," and there is a niri-style mission control view for moving windows between workspaces by dragging.

Where rift is the wrong tool

The licensing situation is the first thing to resolve, and it is not a documentation problem. The repository metadata reports the license as NOASSERTION, meaning GitHub could not map the LICENSE file to a known identifier. The README says rift "began as a fork (and is licensed as such) of glide-wm." A fork inherits its upstream license, and if that license carries obligations, they apply to you as a user or redistributor. Nothing in the repository states which license that is. Read LICENSE directly before you ship rift inside anything, and if you are redistributing it, have someone qualified read it too.

The second limitation is the private API dependency. It buys performance and, in the author's view, reliability, but it means rift lives outside Apple's compatibility guarantees. A macOS update that changes how accessibility or window server internals behave can break rift in ways the project cannot prevent. The experimental feature flag in Cargo.toml is a visible acknowledgment that parts of the event loop and accessibility handling are still being worked out.

Third, the documentation is split. The README is a feature list and a pointer; the substance is on the docs site. If you need a single self-contained reference, or you are evaluating rift for a team that will not read an external site, that split is friction.

Finally, consider the release cadence. v0.6.0, v0.6.1 and v0.6.2 landed on 2026-09-23, 2026-09-25 and 2026-09-27. Three releases in five days is a project moving quickly. That is good if you want current work; it is bad if you need a config format that will not shift under you between upgrades.

rift versus Aerospace, glide-wm and the rest of the macOS tiling field

Aerospace is the natural comparison because the README names it as the project's starting point. The difference is not layout vocabulary, both tile windows. It is the display model. Aerospace is the tool the author left because it could not do fullscreen on one display while tiling another, and rift's stated differentiator is working with "Displays have separate Spaces" enabled. If your setup is a single display, that difference evaporates and Aerospace's maturity becomes the stronger argument.

glide-wm is the other direct comparison, and it is a lineage question rather than a feature question. rift "began as a fork" of glide-wm and "has since diverged significantly." The README states rift is not affiliated with glide-wm. If you are choosing between them, you are choosing between an upstream and a fork that has moved on; the fork carries the license of the original, which is exactly why the LICENSE file matters here.

yabai is a third reference point, mentioned only as a source of reverse-engineered private APIs. The README credits yabai and other projects for that work and states rift is not affiliated with yabai. The relevant contrast is the SIP requirement: rift does not require disabling it, which removes the step that has historically kept people away from the deepest-API window managers on macOS.

Amethyst and the other entries that show up in search alongside rift are not discussed anywhere in the repository, so there is nothing here to compare them against. The honest position is that rift's own README positions it against Aerospace and glide-wm, and that is the comparison the project is willing to defend.

Maintenance, upgrades and what the licence question costs you

The repository is not archived, and the last push was on 2026-09-28. The three releases in the days before that (v0.6.0 on 2026-09-23, v0.6.1 on 2026-09-25, v0.6.2 on 2026-09-27) show a maintainer who is actively landing changes. For an early-stage window manager, that is the maintenance signal that matters: work is happening now.

Upgrade cost is where you should think carefully. Version 0.6.x means the project has not committed to a stable interface. Configuration keys can move, and the Cargo.toml feature set (including the experimental group) can change between releases. A hot-reloadable config makes iteration cheap, but it does not make your config forward-compatible. If you pin a version, you get stability and miss fixes; if you track main, you get fixes and occasional churn. There is no documented migration or rollback procedure, so back up your config before upgrading.

The licence is the unresolved item. NOASSERTION in the repository metadata plus "licensed as such" as a glide-wm fork means the terms are whatever LICENSE says, and the repository does not say what that is. This is not a legal opinion and should not be read as one. It is a statement that you cannot determine your obligations from the README, and that for personal use the question is usually academic while for redistribution it is not.

One more cost that is easy to overlook: rift depends on private macOS APIs, so its maintenance burden is not only the maintainer's. Every macOS release is an event you have to watch, and your upgrade timing for the OS is now coupled to the project's readiness.

Editorial conclusion

rift suits macOS users who want i3-style or scrolling-column tiling without disabling SIP and without turning off 'Displays have separate Spaces'. It is a poor fit if you need a stable, widely documented configuration format or if you depend on a large plugin ecosystem, since the project is young (v0.6.2, released 2026-09-27), forks glide-wm, and its documentation lives on a separate site rather than in the README. Before adopting it, read rift.default.toml against the configuration reference to confirm the keys you need exist, and check the LICENSE file to settle the licensing question the repository metadata leaves open.

Frequently asked questions

Official sources

1. acsandmann/rift on GitHub
2. Issues
3. Project website
4. README
5. Releases