OmniWM

A tiling window manager for macOS, written in Swift 6.4+ and licensed GPL-2.0-only with source-availability requirements on forks and redistributions. 2.4k stars, 94 forks, 887 commits on main, 7 open issues as of 2026-08-09. It requires macOS 26+ (Tahoe) on Apple Silicon, cites Niri and Hyprland as inspiration, and drives the window system through Apple’s accessibility and private APIs rather than any X11 or Wayland path.

Features: multiple layout engines, macOS native tabs, IPC and CLI automation, and a quake-style sticky terminal built on ghostty’s libghostty. Configuration is a single settings.toml under $XDG_CONFIG_HOME/omniwm, live-reloaded when saved, with state kept separately under $XDG_STATE_HOME. Builds are developer-signed and notarized, which the project frames as making it usable inside organisations that enforce Gatekeeper.

The record that routed it here describes a different program

This needs stating plainly, because it is the reason the page exists in this shape.

The hub parked OmniWM on 2026-06-21 from a showcase post on opensourceprojects.dev, with a url: field that was broken on arrival — the literal string https://github.com/ # OmniWM. The showcase describes “a lightweight, modular tiling window manager for X11 (Wayland planned), written in C with Lua scripting for config,” under 100 stars, 13 contributors, depending on xcb, libxkbcommon and lua.

The canonical repository that same showcase names is this one, and it matches on none of those points: macOS instead of X11, Swift instead of C, TOML instead of Lua, 2.4k stars instead of under 100.

Neither claim is silently dropped. What is verified on 2026-08-09 is the repository, and this page describes it. The showcase post is a secondary write-up on an aggregator site (T4 in the hub’s ladder) and is recorded as unreliable for this subject — either it described a different project of the same name, or it was wrong. The practical lesson goes in the hub log: a park record built on an aggregator, carrying a broken canonical URL, was carried for seven weeks and would have been ingested as fact if the primary source had not been fetched.

Why a window manager belongs in this spoke

It is the clearest case of the foss-application pattern applied to the computing environment itself. A window manager is not a tool you open — it is the thing that decides how everything else appears, normally supplied by the platform vendor and normally not replaceable at all. Doing this on macOS is the hard version: no compositor to swap, no display protocol to implement against, so the project drives accessibility and private APIs that Apple can change without notice.

Two details are worth keeping for the spoke’s larger argument. Live-reloaded TOML puts configuration in a plain file the user owns, and signed and notarized builds are an interesting concession — a GPL project paying Apple’s identity toll so that its users can install it without fighting the platform. Replacing the vendor’s software often means accepting the vendor’s distribution terms to do it.

What is not established

• Stability against OS updates. A window manager on private APIs, pinned to macOS 26+ and Apple Silicon, is one point release away from breakage. Nothing here records how that has gone.
• No comparison to yabai or Amethyst, the obvious incumbents, is held.
• Governance and funding are unrecorded; 887 commits with 7 open issues is a healthy-looking ratio, and nothing here says by whom.

Connections

With anysoftkeyboard and termux (cross-wiki), one of three sources here that replace part of the environment the platform vendor supplies — a keyboard, a shell, a window manager. All three are on platforms designed to discourage exactly that, which is the more interesting fact about them than their feature lists.