Loop (mrkai77/Loop): a radial-menu window manager for macOS

The problem Loop solves, and who it is for

macOS ships window controls that are adequate for one or two windows and tedious beyond that. Dragging a corner to fit a half or a quarter of the screen is imprecise, and snapping behaviour has changed across macOS releases. Loop targets the moment when you know where a window should go but do not want to aim a mouse at a title bar to get it there.

The README describes the app as something that "simplifies window management for you", with a radial menu triggered by a simple key press. That framing matters, because it tells you the intended interaction: hold a key, flick the cursor toward a direction, release. A second path exists for people who dislike gestures. The README states that users who prefer keyboard shortcuts can assign a key to work alongside the trigger key, so the same set of actions is reachable without moving the pointer in an arc.

It is not aimed at someone who wants the computer to decide the layout. There is no automatic tiling described in the README. Every arrangement is a deliberate act, which is either the point or a dealbreaker depending on how you work.

How the trigger key, radial menu and preview fit together

The mechanism is a held modifier. The README says the trigger key "must be held down or pressed to activate certain features within Loop", and that it can be set in the Behavior tab of Settings. It can consist of one key or several. While it is held, cursor movement selects a direction, and the window is moved or resized to match.

The radial menu is the visible part of that gesture, and it is optional. The README says it is fully customizable in width, shape and color, and that "both the cursor interaction and the radial menu itself are independently toggleable". That separation is the interesting design decision: you can keep the directional gesture and hide the menu, or keep the menu and disable cursor interaction. Neither is forced on you.

A preview window shows the resize action before it is committed. Padding, corner radius, border color and border width of that preview are adjustable. Cycles extend the same idea across repeated presses: the README describes performing multiple window manipulations in quick succession by pressing the same key combination repeatedly, or by left-clicking repeatedly. Stash is a separate feature that hides windows at a screen edge and brings them back when you hover near that edge or use a keybind.

Under the hood the repository is a Swift project with an Xcode project file at the root and separate directories for the app, a dock tile component, tests, an updater helper and shared code. That layout is consistent with a native AppKit and SwiftUI application rather than a script wrapper, but the README does not document the internal architecture beyond what the features imply.

Installing Loop with Homebrew and running a first action

Two installation paths are documented. Homebrew is the shorter one:

brew install loop

After that, Loop needs Accessibility permission to move other applications' windows. The README does not spell out the exact prompt sequence, so expect macOS to ask when the app first tries to act on a window. The manual route is the release page, where the README points to the latest .zip file at the bottom of the page, or directly to the download URL it lists. Compatibility is stated as macOS 13 and later.

The first real use is setting the trigger key. Open Settings, go to the Behavior tab, and choose the key you will hold. Caps Lock is a common choice, but macOS does not hand it over directly. The README gives three options. The first is to remap it in System Settings under Keyboard, then Keyboard Shortcuts, then the Modifier Keys tab, remapping Caps Lock to Control, and repeating that for every connected keyboard before selecting Right Control as the trigger in Loop. The second is an external app such as Hyperkey or Karabiner Elements. The third is scripting.

Loop exposes a URL scheme, which is useful for testing without touching the UI:

open "loop://direction/right"     # Move window to right half
open "loop://action/maximize"     # Maximize window
open "loop://screen/next"         # Move to next screen

If nothing moves, the permission is usually the cause. The README also documents listing commands, which is the fastest way to see what the installed build accepts:

open "loop://list/all"           # List all commands
open "loop://list/actions"       # List window actions
open "loop://list/keybinds"      # List custom keybinds

Actions can be chained in a shell script, and the README shows a sleep between two `open` calls to let the first settle.

Where Loop gets in the way

The gesture model has a learning cost that the README does not really acknowledge. Holding a key and sweeping the cursor is fast once it is muscle memory, but it competes with every other use of that modifier. If you pick a key you already use for application shortcuts, you will trigger Loop instead. The Caps Lock workaround exists precisely because the good keys are taken, and it requires either a system remap on every keyboard you own or a third-party remapper.

Accessibility permission is a real constraint, not a formality. An app that moves other windows has to be trusted at that level, and the README does not document what Loop does when the permission is revoked or when it is running on a managed Mac where the permission is blocked. Nothing in the README describes a fallback mode.

The release history is worth reading before you install. The newest entry is a 1.4.3 prerelease dated 2025-11-08, while the stable entries are 1.4.2 from 2026-01-26 and 1.4.1 from 2026-01-12. That ordering means the prerelease is older than the stable releases listed above it, so the version numbers alone will not tell you which build is newest. Check the release page rather than assuming the top entry is current.

Finally, Loop is the wrong tool if you want windows to arrange themselves. Nothing in the README describes automatic layout, and the whole design assumes you issue an instruction each time.

Loop against keyboard-first managers like Rectangle

The obvious comparison is with shortcut-driven managers, and Rectangle is the reference point most macOS users already know. The difference is not the set of window positions. Both cover halves, quarters and thirds, and Loop's documented action list includes Fullscreen, Maximize, Almost Maximize, Centre, MacOS Centre, Minimize, Hide, the four halves, the four quarters, and horizontal thirds from Right Third through Left Third.

The difference is how you select one. Rectangle-style tools bind each position to its own key combination, so the cost is memorising a grid of shortcuts and the benefit is that one press equals one result. Loop binds a single trigger key and derives the position from cursor direction, so the cost is one gesture and the benefit is that you do not need a shortcut per position. Loop also draws a preview before committing, which a plain shortcut cannot do, and it layers cycles on top so repeated presses walk through successive manipulations.

The scripting surface differs too. Loop's URL scheme means a shell script or AppleScript can drive it, and the README shows both an `open "loop://..."` form and an `osascript` form that activates the app or opens a location. That makes Loop scriptable in the same way a shortcut-based manager usually is not, without writing a plugin.

Licence, build and upgrade cost

Loop is GPL-3.0. For an end user installing a signed build from the release page or Homebrew, that licence mostly matters if you intend to redistribute the app or ship a modified version inside another product. Copyleft terms attach to derivative distribution, so a fork that bundles Loop into a commercial tool carries obligations that a permissive licence would not. This is a description of the licence identifier, not legal advice; read the LICENSE file at the repository root if the distinction affects you.

Upgrade cost is low by construction. Homebrew users get updates through the usual package flow, and the manual route is a fresh download from the release page. The repository also contains a LoopUpdaterHelper directory alongside the app target, which suggests an in-app update path, though the README does not describe how it works or when it runs.

Building from source is a different proposition. The root holds Loop.xcodeproj and a .swiftformat file, so the expected route is Xcode with the project open, and the LoopTests directory implies a test target. The README does not document build steps, minimum Xcode version, or code signing requirements, so anyone forking should expect to work that out from the project file. Maintenance activity is visible in the repository: the default branch is develop and the last push was on 2026-09-11.

Editorial conclusion

Adopt Loop if you work on macOS 13 or later, want window placement driven by a held trigger key and cursor direction, and are comfortable granting Accessibility permissions to a GPL-3.0 app whose newest release is a 1.4.3 prerelease from 2025-11-08. Do not adopt it if you need a tiling manager that rearranges windows automatically, or if you cannot run a helper that needs Accessibility access. Before installing, open the release page and confirm which build is current for your Mac, then check the Behavior tab to see how the trigger key is configured on your keyboard.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. mrkai77/Loop on GitHub
4. README
5. Releases