# Glide: a tiling window manager for macOS that respects Spaces

> Glide is an Apache 2.0 or MIT licensed Rust tiling window manager for macOS, built to be adopted alongside Spaces rather than instead of them, with a TOML configuration you can reload as you save, a layout that is restored per login session, and the mouse handling that a tiling manager on a trackpad usually gets wrong. The judgement is that the Spaces integration is the design, and that the dependency list shows how much of the work is in talking to macOS rather than in laying out windows.

**tmandry/glide** — A tiling window manager for macOS

- Repository: https://github.com/tmandry/glide
- Website: https://glidewm.org/
- Stars: 695 · Forks: 24
- Language: Rust
- License: Apache-2.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/tmandry-glide

## A tiling window manager that does not replace Mission Control

Glide is a tiling window manager for macOS, and it takes inspiration from window managers like i3, Sway and Hyprland.

What makes it different from a port of those is the first thing the readme lists. It integrates with Spaces, and the instruction is to adopt it incrementally, using Mission Control and moving between spaces as you normally would.

That is the design decision the whole project rests on. A conventional tiling window manager assumes it owns the screen, and on macOS that means fighting the system's own space model, the animation, the exposé behaviour and the app switching. Glide instead manages a space only when you tell it to, and leaves everything else alone, so the tiling behaviour is something you opt into per space rather than a global regime.

The other two headings in the readme are about the two things that make a tiling manager unpleasant on a laptop. The first is keyboard focus with trackpad enhancement, which means interactive resizing and the two options that make a trackpad usable with a tiling layout, mouse-follows-focus and focus-follows-mouse, so that the pointer and the focus are not fighting each other. The second is adapting to the environment, with the layout customised as you move between an external monitor and being on the go, which is a different layout for a different screen rather than one layout scaled.

The project is written in Rust and is licensed under either the Apache License 2.0 or the MIT licence, at your option, with the author being Tyler Mandry. The home page is glidewm.org, the newest release is v0.2.16 from 2026-09-28, and the last push was on 2026-10-19.

## One key press manages a space, and it resizes everything

The quick start is two commands, and then one key combination.

```
brew install glide
glide launch
```

The first time it runs, Glide asks for Accessibility permissions, which on macOS is the permission to read and manipulate the windows of other applications. There is no way around it for a window manager, and the readme says so plainly rather than burying it.

The important setting is a system one. Glide requires Displays have separate Spaces to be turned on to work properly with multiple monitors, which is the default on macOS and is found under System Settings, Desktop and Dock, Mission Control, and if you change it you must log out and back in for it to take effect. That requirement is a consequence of the design, since Glide manages one space at a time, and the per space model only works if the spaces are genuinely separate.

Once it is running, the combination of Option and Z starts managing the current space, and the readme warns that this will resize all your windows. Pressing the same combination again stops managing the space, and to exit Glide entirely the combination is Option and Shift with E. The readme also notes that Option and Alt are synonyms for the same key, which saves a confusing search for the Alt variant in the documentation.

So the lifecycle is: launch, toggle a space on, work in it, toggle it off, and the windows you had before are still there.

## A configuration file you can reload as you save

The key bindings live in a file, and the readme explains where the defaults are and where your copy goes.

The defaults are in glide.default.toml, and your own configuration is a file at ~/.config/glide/glide.toml, or at ~/.glide.toml, and you can change it either by restarting Glide or by running the config update command:

```
glide config update
```

And there is a watch flag, which the readme presents as a tip, to apply the changes as you save. That is the small feature that makes the whole configuration approach pleasant, because a window manager configuration is something you change while you are using it, watching the change take effect immediately rather than restarting and losing your window layout.

The configuration is TOML, and the settings section inside it is where behaviour lives, with the readme pointing at a specific setting under [settings] for the restore behaviour. The file uses the same format as most of the modern Rust configuration files, which means it can be generated, diffed and reviewed like code, and a window manager that manages your windows benefits from the same discipline as the rest of your setup.

## Layout restore is scoped to a login session

The save and restore behaviour is the part of the readme with the most precise wording, and the precision is necessary.

When you exit Glide with the save and exit key binding, which is Option, Shift and E by default, or with the Quit menu item, it saves your layout and which spaces are enabled. The next time Glide starts in the same login session, it restores them. To start with a fresh layout instead, the launch command takes a flag:

```
glide launch --no-restore
```

To make that the default, the readme says to set auto_restore to false under the settings section in the configuration, and then the launch command restores for that one launch.

The scope is the detail. Saved state is not restored after logging out or restarting the machine, and the reason is obvious once you see it, because a tiling layout is tied to a set of applications, and the set of applications you had open on Monday is not necessarily what you want on Tuesday.

So the feature is deliberately bounded to a login session, where the applications you were using are the ones you are about to use again, and it is a per space decision because the readme mentions which spaces were enabled as part of what gets saved.

## Panic abort, and a feature flag kept for compatibility

The Cargo manifest has two comments that explain the engineering decisions better than the code would, and both are worth quoting for what they say about running inside a system process.

The first is about the release profile. There is no need for unwinding, and aborting means the project does not have to worry about propagating panics to the main CFRunLoop thread. Since panic abort tests are not stable yet, the test dependencies are always built with panic set to unwind, so the development builds continue to use unwinding with a panic hook that aborts, which lets the dependency builds be reused.

That is a small but telling piece of engineering. A macOS window manager runs inside a process that owns the run loop of the login session, and an unwinding panic across that boundary is a much worse failure than an abort, so the release build trades the ability to catch panics for a clean crash.

The second comment is about the exec_cmd feature. It is a deprecated compatibility flag, and the feature is enabled by default and launches through LaunchServices, with the note that the flag is kept for compatibility with existing scripts that still pass it, and that it will be removed at some point. Privileged execution now requires unsafe_privileged to be true in the configuration, which is a separate setting.

The rest of the manifest describes a typical Rust application, with a clap command line interface using derive, anyhow for errors, bitflags for the option types, ascii_tree for the layout output, core-foundation and core-graphics for the macOS side, and a git dependency on an accessibility crate that is being migrated to objc2. The build uses a single codegen unit and the package is marked as not publishable, because it is an application rather than a library.

## The dependencies show how a macOS window manager is written

The acknowledgements in the readme are the most useful description of the project available.

Glide builds on the work of many who came before, and the readme names Yabai as containing a wealth of information about the tricks and techniques needed to write window managers on macOS. That is the honest attribution for the hard part, because the techniques for moving and resizing other applications' windows on macOS are not documented by Apple in a way that makes them easy.

The objc2 crates and related ones make it possible for Glide to be written in Rust, which is the second piece. The Objective-C runtime is the only way to talk to the window server, and the objc2 family is what makes that possible from a systems language, so the choice of Rust and the choice of objc2 are the same decision.

The third is tracing, which provides tree-structured logging to follow the complex asynchronous flows that are inherently required in a macOS window manager like Glide. A window manager is a state machine driven by events from several sources at once, the window server, the input, the configuration file and the screens, and the log has to be readable enough to reconstruct what happened.

The manifest confirms the shape. There is the accessibility crate and its system counterpart, both from a git branch rather than a published version, which is the objc2 migration in progress, and the objc2 and objc2-app-kit crates for the runtime itself, core-foundation and core-graphics for the graphics side, and a hotkey crate for the key handling.

The repository also has an ARCHITECTURE.md, several example programs under examples, a devtool, a group indicator example, a window making example and a test for updating the view model, and a set of crates under crates.

## Four ways to install, including a symlink into /usr/local/bin

The installation section covers the ways to get Glide onto a Mac, and one of them is unusual enough to be worth reading carefully.

The easy one is Homebrew, with brew install glide, and the readme notes that if you do not have Homebrew there is a manual installation section. The manual route is to download the latest release, open the disk image and drag Glide into Applications, and then, and this is the recommendation, install the glide command line interface by making a symbolic link:

```
sudo ln -s /Applications/Glide.app/Contents/MacOS/glide /usr/local/bin
```

The point of the symlink is that Glide is both an application and a command, and the application has to be in Applications for macOS to treat it properly while the command has to be on the path for the scripts that talk to it. The link points into the application's own binary, so there is only one copy of the program on the machine.

To run Glide at login, there is a service command, glide service install, which installs it as a login item.

Building from source needs Rust and the latest Xcode command line tools, and then a clone, a cd and cargo run --release. The accessibility permission has a useful subtlety here, because instead of enabling it for Glide you can enable it for whatever application your terminal is running in, and the permission then covers the process that is actually making the calls.

The licences are at the end, and there are two of them, Apache 2.0 and MIT, at your option.

## Conclusion

Glide fits a macOS user who wants tiling without giving up Mission Control or the per space workflow, because a space is managed only while you ask for it, one key press starts and stops it, and the layout is saved and restored for the session. It is the wrong choice if you want a window manager that takes over the whole screen, because Glide deliberately coexists with the system rather than replacing it, and it is the wrong choice if you are on a multi monitor setup that does not have separate Spaces enabled, since the readme says it has to be on and changing it needs a log out. Before you install it, check that setting, and read the acknowledgement section, because the project credits Yabai for the hard parts of writing a macOS window manager and the objc2 crates for making it possible in Rust at all.

## FAQ

### What is Glide?

It is a tiling window manager for macOS, written in Rust and inspired by i3, Sway and Hyprland. It integrates with Spaces so you can manage one space at a time with a key press, and it adds mouse-follows-focus and focus-follows-mouse for trackpad users.

### How do I install and start Glide?

Run brew install glide and then glide launch, or download the release, drag the application into Applications and link the CLI with sudo ln -s /Applications/Glide.app/Contents/MacOS/glide /usr/local/bin. You will need Accessibility permissions, and Glide requires Displays have separate Spaces to be enabled for multiple monitors.

### How do I change the key bindings?

Create a configuration file at ~/.config/glide/glide.toml or ~/.glide.toml, then run glide config update, or glide config update --watch to apply the changes as you save them. The defaults are listed in glide.default.toml.

### Does Glide restore my window layout?

It saves the layout and which spaces are enabled when you exit with the save and exit binding, and restores them the next time it starts in the same login session. Saved state is not restored after logging out or restarting the machine, and glide launch --no-restore starts fresh instead.

## Sources

- [License: Apache-2.0](https://github.com/tmandry/glide/blob/main/LICENSE)
- [Project website](https://glidewm.org/)
- [README](https://github.com/tmandry/glide/blob/main/README.md)
- [Releases](https://github.com/tmandry/glide/releases)
- [tmandry/glide on GitHub](https://github.com/tmandry/glide)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tmandry-glide