OmniWM: a Niri-style scrolling tiling window manager for Apple Silicon Macs

What OmniWM solves, and who it is actually for

macOS ships a window model built around floating, individually placed windows. Every tiling window manager on the platform is a workaround for that, and each one picks a different layout metaphor. OmniWM's README describes a project that refuses to pick just one: Niri-style orientation-aware scrolling containers and Hyprland-style Dwindle BSP layouts, selectable per workspace.

That per-workspace selection is the distinguishing claim. On a Linux setup you choose a compositor and live with its layout algorithm. Here, the README states that the two layout families coexist and that the choice is made workspace by workspace. A reader coming from Niri will recognise the scrolling column model: windows sit in a strip you scroll through rather than a grid that reflows. A reader coming from Hyprland will recognise Dwindle, the BSP variant that splits the focused window along its longer axis. Putting both behind one workspace switch is a design decision aimed at people who want a reading-and-reference workspace on one monitor and a dense split tree on another.

The audience is narrow by construction. The README states macOS 26 or later and Apple Silicon. That is not a soft recommendation; it is the supported configuration. Anyone on an Intel Mac or an older macOS release is outside the stated target, and the repository gives no indication of a fallback build.

It is also signed and notarized, which matters for a window manager. Tools in this category frequently ask the user to disable Gatekeeper checks or grant Accessibility permissions to an unsigned binary. OmniWM's README says it is Developer ID-signed and Apple-notarized, so the install path does not require that particular leap of faith.

How the two layout engines coexist

The repository layout shows a Swift package: Package.swift, Sources/, Tests/, plus a Makefile that drives the build. The README does not publish an architecture diagram, so the internal split between the scrolling container engine and the Dwindle BSP engine is not documented at that level. What is documented is the observable behaviour: a workspace is assigned one of the two layout families, and the windows on that workspace are arranged accordingly.

The two models differ in what happens when a new window appears. In a Dwindle BSP tree, a new window splits the space of the focused window, so the tree grows and every existing window shrinks. In a scrolling container, new windows extend the strip and the viewport scrolls; existing windows keep their width. That difference is why the per-workspace switch is useful rather than decorative. A workspace where you read long documents behaves badly under continuous re-splitting, and a workspace where you compare four terminals behaves badly under scrolling.

Beyond layout, the README lists multi-monitor routing and optional local CLI/IPC automation. Multi-monitor routing means workspace-to-display assignment is handled by the window manager rather than by dragging windows between screens. The CLI and IPC layer is described as local and optional, which is the right default: a window manager that exposes an IPC socket is scriptable, and one that exposes it by default is attack surface. The README does not document the IPC protocol itself in the repository, and the guides live on the project website.

One thing the README is explicit about is the compatibility page, linked as known-limitations. That page existing at all is a signal worth taking seriously. Tiling window managers on macOS interact with applications that draw their own window chrome, and the documented limitations are the place where those interactions are recorded.

Installing OmniWM and getting a first workspace tiled

The README does not contain install commands. It links to an install guide at omniwm.app/guides/install/ and a quick-start guide at omniwm.app/guides/quick-start/, and those two pages are where the project says to get it. Because the repository does not reproduce those steps, there is no install command to quote here without inventing one, and inventing one would be worse than leaving it out. Go to the install page.

What the repository does document is the developer build path, which is a different thing from installing the app. The Makefile defines a setup target that provisions pinned tooling, and a doctor target that checks the environment:

make setup
make doctor

The setup target runs Scripts/dev-tools.sh setup. The doctor target runs the same script with the doctor argument. The Makefile also pins SwiftFormat and SwiftLint versions through Scripts/dev-tools.env and fails the build if the installed versions do not match, which is the kind of friction that saves arguments later.

Building the app itself goes through a preflight check for a Ghostty library directory, then a Swift build for arm64 only:

make build

The Makefile expands this to ./Scripts/ghostty-preflight.sh verify followed by swift build --arch arm64 with LIBRARY_PATH pointing at the directory that the preflight script prints. The arm64-only architecture flag matches the README's Apple Silicon requirement; there is no x86_64 target in the Makefile.

For day-to-day use while developing, the Makefile separates installing a development build from switching between development and release builds:

make dev-install
make use-dev
make use-release

make dev-install runs Scripts/omniwm-dev.sh install. make use-dev and make use-release run the same script with use dev and use release. The run target is an alias for dev-install, so make run and make dev-install do the same thing. If you only want to use OmniWM rather than modify it, skip all of this and use the install page.

The macOS 26 floor is the real adoption cost

Every limitation in this project descends from one constraint: macOS 26 or later, Apple Silicon only. That is a recent OS floor. A window manager is the kind of tool people install on a machine they have been running for years, and a machine that cannot be upgraded to macOS 26 cannot run OmniWM at all. The README offers no compatibility mode, no older-OS branch, and no Intel build. The Makefile's swift build --arch arm64 confirms the single-architecture target.

There is a second, quieter cost. The repository is a Swift package with a Makefile and a Scripts/ directory full of shell tooling, and the user-facing documentation lives on the website rather than in docs/ or the README. For a reader who wants to evaluate the configuration surface before installing, that is a gap: you cannot diff the config format against your current setup by reading the repository. The README does not document the configuration file format, the keybindings, or the IPC protocol. It points at the guides.

Accessibility permissions are the third thing to expect. The README does not describe the permission flow, but a window manager that moves other applications' windows on macOS operates through the accessibility APIs, and that is a system-level grant the user makes deliberately. Nothing in the repository suggests this is avoidable.

None of these are defects in the code. They are the shape of the project: a signed, notarized, single-architecture macOS application with a narrow supported configuration and documentation hosted outside the repository. If your machine matches the target, the constraints mostly disappear. If it does not, no amount of configuration will help.

AeroSpace is the comparison that matters

The searches people run against this project pair it with AeroSpace, and the pairing is fair because both are macOS tiling window managers written for people who want keyboard-driven layout rather than drag-and-drop. The difference is in the layout model, not in the platform support.

AeroSpace is built around a tree of containers in the i3 tradition: you split horizontally or vertically, and the tree is the layout. There is no scrolling strip and no per-workspace choice of algorithm. OmniWM's README describes something different: two named layout families, Niri-style scrolling containers and Hyprland-style Dwindle BSP, selectable per workspace. If you have used Niri on Linux and want that behaviour on a Mac, AeroSpace does not offer it; that is the gap OmniWM is aimed at.

The trade-off runs the other way too. A single layout model is easier to reason about and easier to document. OmniWM carries two engines, and the README's own structure reflects the cost: the interesting configuration detail is on the website, and the repository links to a known-limitations page rather than claiming uniform behaviour. Two layout families also mean two sets of edge cases when an application refuses to be tiled.

The other names in the search data, HyprSpace, HyprMac, StackWM and Paneru, are further points in the same space. The repository gives no comparison against any of them, so the honest position is that OmniWM's differentiator as documented is the per-workspace choice between scrolling and Dwindle, plus the signed and notarized distribution. Judge it on that, not on a feature matrix the project has not published.

Licence, maintenance and what an upgrade costs you

OmniWM is GPL-2.0. For an end user installing a window manager on a personal Mac, that licence imposes nothing unusual: you can run it, and if you redistribute a modified binary you take on the obligations the licence sets out. For anyone embedding OmniWM's code in another product, GPL-2.0 is a copyleft licence and the terms differ substantially from a permissive one. That is a statement about the licence text, not legal advice; if you are shipping something, read LICENSE and talk to someone qualified.

The maintenance signal is straightforward. The repository is not archived, and the last push was on 2026-09-23. Three releases landed in the week before that: v0.7.0 on 2026-09-16, v0.7.1 on 2026-09-19, and v0.7.2 on 2026-09-23. That is a project moving at a fast cadence, and fast cadences cut both ways. You get fixes quickly. You also get a configuration surface that may shift between minor versions, and the README does not document a migration path between releases or a config schema version.

Upgrade cost is therefore mostly about the config and the permissions, not the binary. The Makefile shows the developer-side discipline: pinned SwiftFormat and SwiftLint versions, a doctor target, a setup target, and a test-dev-tools target that runs python3 -m unittest discover -s Tests/DevToolingTests. That tooling is for contributors. If you are a user, your upgrade cost is re-reading the guides after a minor version bump and checking the known-limitations page for changes. The README does not describe an automatic update mechanism.

Editorial conclusion

Adopt OmniWM if you are on an Apple Silicon Mac running macOS 26 or later and you want to choose between a scrolling column model and a Dwindle BSP tree per workspace, with CLI and IPC automation available. Do not adopt it if you are on Intel hardware, on an older macOS release, or if you need a configuration format that a non-programmer can edit: the README points to a website quick-start guide rather than documenting the config surface in the repository. Verify the known-limitations page before you commit, and check whether your macOS version meets the stated floor.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. OmniNull/OmniWM on GitHub
3. Project website
4. README
5. Releases