941 Tiles

Open the menu bar, click an app with two or more windows, and every one of its windows snaps into an even, gap-padded grid — that's the demo above, and it's the entire interaction model. You don't pick a layout; you pick an app.

The click means "all of my terminal windows," not "this window goes top-right." On a real desktop you think "editor and terminal side by side," and that's the instruction 941 Tiles takes — it never makes you place windows one at a time. Beyond that there's a gap slider and a watch toggle, and that's the entire product.

The first version worked the way you'd expect: macOS has an Accessibility system that, with your permission, lets one app see and move another app's windows. Built on that, the app ran flawlessly for weeks of development. Then the App Store test build went onto a second Mac: permission granted, the app reported access was on — and it could read zero windows.

Not a bug. Every Mac App Store app runs in Apple's sandbox — a rule that an app may only touch its own things, precisely so it can't spy on or interfere with the rest of your Mac. Reaching into another app's windows is exactly what the sandbox exists to stop, and no permission or setting unlocks it. An Apple engineer put it flatly on the developer forums: "It's not possible to use the Accessibility APIs from a sandboxed app… your only path forward here is to directly distribute your app."

That verdict is why the tilers on the store — Magnet, Moom, BetterSnapTool — all predate the 2012 sandbox mandate, and why virtually every window manager born since (Rectangle, Swish, Loop) sells outside the store. The obvious move was to give up on the App Store. The better move was to stop asking for permission the sandbox would never grant.

The answer was already on every Mac: Shortcuts, Apple's own automation app, ships with actions called Find Windows, Move Window, and Resize Window — and Shortcuts is allowed to move windows because it's Apple's. So 941 Tiles never touches another app's windows. It computes where every window should go, then hands that plan to a companion Shortcut it installs once, and Apple's own engine does the moving. Delegation, not permission — a pattern spotted in the wild and verified from the open-source snApp.

<key>com.apple.security.app-sandbox</key>
<true/>
<key>com.apple.security.automation.apple-events</key>
<true/>
<key>com.apple.security.scripting-targets</key>
<dict>
    <key>com.apple.shortcuts.events</key>
    <array>
        <string>com.apple.shortcuts.run</string>
    </array>
</dict>

That's the full extent of the app's privileges: sandboxed, allowed to send one kind of Apple Event, to exactly one target — Shortcuts. There is no window-control permission because none exists to ask for.

// The grid, as JSON, in window stacking order: {"app", "frames": [{x,y,w,h}, ...]}
let payload: [String: Any] = [
    "app": appName,
    "frames": assigned.map { [
        "x": Int($0.origin.x), "y": Int($0.origin.y),
        "w": Int($0.width),    "h": Int($0.height),
    ] },
]

// Apple's runner does the moving — the only privileged actor in the story.
let app: ShortcutsEvents? = SBApplication(bundleIdentifier: "com.apple.shortcuts.events")
let shortcut = app?.shortcuts?.object(withName: "941 Tiles") as? ShortcutObject
shortcut?.run?(withInput: json)

Reading the window list was never the problem — the sandbox only forbade moving, and moving is now Apple's job. Two details that made it feel right: windows land near where they already were, and the invisible phantom panels macOS reports (but no one can see) get filtered out. The honest cost to the user is a one-time "Install Shortcut" and a single automation consent. After that the Shortcuts run is invisible — one click, and the grid lands.

Watch mode (the eye icon) re-tiles an app as its windows open and close. Developer ID builds ride Accessibility notifications; the sandboxed store build — where those notifications don't exist — polls the window server and re-tiles on a count change. Same behavior, two mechanisms.

Watch mode resets each session, on purpose. Anything that rearranges your screen automatically should be a decision you made today, not a setting you forgot six months ago. Persistent watch mode would be a small convenience and a categorical loss of trust the first time a screen rearranged itself unexpectedly.

Not another set of keyboard shortcuts to learn — there is nothing to memorize. Not a productivity dashboard — no analytics, no telemetry, no network access; there is nothing to leak because there is no infrastructure to leak it through. Not a subscription — $4.99 once, owned forever; there's no ongoing service to fund.

"Not possible" sometimes means "not possible the way everyone does it." The Accessibility wall was real — Apple's own DTS said so — but the goal was never "use the Accessibility API"; it was "tile the user's windows." Restate the goal, and it turns out Apple ships a sanctioned way to do exactly that.

The design lesson stayed the same: refuse every feature that would turn one click into a shortcut scheme or a settings pane. One click. App as the unit. Nothing to memorize, nothing to configure, no telemetry — and, unlike any window manager born since 2012, on the Mac App Store, in 17 languages.