The five things that happen between the keypress and the snap. A short technical tour of Apricot.
You press ⌘⌥ and an arrow. A window jumps to a half of the screen, or to a corner. From the user's side, that's the entire product. From the app's side, five things have to happen between the key going down and the window landing.
This page walks through all five, in order. It's short enough that you can hold the whole pipeline in your head by the end.
Apricot is $3. One-time purchase, no subscription. Universal binary (Apple Silicon + Intel), signed and notarized, needs Accessibility permission, requires macOS 14.4 Sonoma or newer.
Every time Apricot launches, it registers a small set of keyboard shortcuts with the system: ⌘⌥+←, ⌘⌥+→, ⌘⌥+↑, ⌘⌥+↓, ⌘⌥+return for maximize, and ⌘⌥+C for the center-70% snap. The ⌘⌥ modifier is configurable in Apricot's preferences. Registration goes through Carbon, which has been the endorsed path for global keyboard shortcuts on the Mac for a very long time.
Carbon looks anachronistic — it's a C API from before Cocoa. Apple has tried a few times to give it a modern replacement and each time backed off, because global keyboard shortcuts turn out to be a genuinely awkward thing to build on top of Cocoa's event loop. So for now: Carbon. Most keyboard-driven Mac apps are doing the same thing underneath, including the ones that market themselves as extremely modern.
When the user's key combination fires anywhere on the machine, macOS routes the event to Apricot, which identifies which chord fired and hands control to the next step.
Apricot then decides where the window should go. For a plain half snap, that's trivial — ⌘⌥+← means "left half," and there's nothing more to work out. For a corner snap, there's a small bit of state: a state machine tracks the last horizontal and vertical keypress, so an orthogonal pair reads as a corner. Left-then-up is top-left. Down-then-right is bottom-right. And so on.
The result is a snap target — one of ten: four halves, four corners, maximize, or center-70%. Nothing else about the user's intent gets encoded.
To move a window, Apricot needs a reference to it. Every third-party window manager on macOS uses the same channel to get that reference: the Accessibility API, the tree of UI-element handles Apple exposes for assistive tech and for automation. This is the permission you grant when you tick Apricot's box in System Settings → Privacy & Security → Accessibility.
Apricot asks for the frontmost application, then for its focused window, then for that window's current position and size. This is the only part of the pipeline that touches any process other than Apricot's own. If you're curious about the boundary here, the no-telemetry page covers what Apricot can see and what it doesn't.
Now the arithmetic. Apricot is multi-monitor aware, and every snap target is computed as a rectangle relative to the target screen's visibleFrame — the screen rectangle excluding the menu bar and the Dock:
Because the geometry comes from visibleFrame, hiding the Dock or attaching an external display changes the bounds a snap lands in without Apricot needing to know anything special about either.
Last step. Apricot writes the new position and size to the window handle it got in step 3, through the same Accessibility API. The system routes those writes to the target app, which repositions and resizes its own window.
The move isn't a hard cut: snaps animate with a smoothstep tween over six frames. That's short enough to still feel like a keyboard operation rather than a mouse gesture, and long enough that your eye can follow the window to where it went instead of re-finding it.
One boundary worth knowing about, because it applies to every third-party window manager and not just this one: Accessibility geometry writes are a request to the target application, not a command to the window server. Apps that manage their own geometry — full-screen apps in particular, which belong to the system's Spaces machinery — may decline. That's expected macOS behaviour, and the honest thing to do is name it.
Apricot deliberately doesn't ship some things that other window managers do:
A window snapper is a piece of software with enormous authority — it holds a handle to the window you're looking at and moves it. The trade Stonefruit makes for that trust is to keep the surface area small enough that a curious buyer can hold the whole thing in their head in one sitting.
This shape of app also rewards restraint. There's no benchmark to chase and no roadmap to graduate to. A window snapper that snaps windows reliably, on every macOS release, without needing an update, is the goal. Anything added to the pipeline is something that can drift, break, or need maintenance later.
The pipeline, in one sentence: Carbon global hotkey → decide the target from directional state → Accessibility handle to the frontmost window → compute the rectangle from the screen's visible frame → write the new position and size. Five steps, one framework of Apple's per step.