The Mac App Store Won't Let Window Managers Exist. I Shipped One Anyway.

An Apple Developer Technical Support engineer told me my app was impossible: “It’s not possible to use the Accessibility APIs from a sandboxed app… your only path forward here is to directly distribute your app.”¹ The app was a window tiler, the Accessibility API is the thing every window manager is built on, and every Mac App Store app runs inside the sandbox that forbids it. Last week, 941 Tiles went live on the Mac App Store anyway: one click in the menu bar and all of an app’s scattered windows snap into an even grid. The sandbox rule never bent. The trick was noticing that macOS already contains a privileged window-mover with Apple’s full blessing, and it takes JSON.

TL;DR

• App Sandbox categorically blocks cross-app Accessibility calls, no entitlement unlocks it, and every Mac App Store app must be sandboxed. The window-manager category has been effectively closed to newcomers since June 2012; the tilers still on the store predate the mandate and run unsandboxed forever.¹³⁴
• The sanctioned door: a sandboxed app may drive Apple’s Shortcuts engine via Apple events, and Shortcuts ships Find Windows / Move Window / Resize Window actions that move other apps’ windows with Apple’s own privileges.²⁵ My app computes where every window should go; a companion Shortcut does the moving. Delegation, not permission.
• The engineering that made it real: authoring the companion .shortcut programmatically as a binary plist of WFWorkflowActions, a JSON frame-payload contract keyed to window z-order, guard rails against phantom windows and index overruns, and a dual-engine codebase that uses direct Accessibility in Developer ID builds and Shortcuts delegation in store builds.
• First successful run on the machine that had failed five store builds: four scattered terminal windows to exact quadrant frames in 0.6 seconds.
• Credit where it is due: the mechanism is proven in the wild by snApp (open source, 2023) and Align (2024). Reading snApp’s source is what turned “impossible” into a build plan.²

The Wall

The first version of 941 Tiles was a classic menu-bar tiler. macOS has an Accessibility system that, with the user’s permission, lets one app enumerate and move another app’s windows (AXUIElementSetAttributeValue on window position and size attributes). Built on that, the app ran flawlessly for weeks of development. I staged the whole App Store Connect listing: metadata in 17 languages, screenshots, pricing, 21 uploaded builds.

Then a TestFlight build went onto a second Mac. Accessibility permission granted, the app reporting access on, and it could read zero windows.

Not a bug. Every Mac App Store app runs in Apple’s App Sandbox, a containment rule that an app may only touch its own things, precisely so it cannot spy on or interfere with the rest of your Mac.⁴ Reaching into another app’s windows is exactly what the sandbox exists to stop. Development builds run unsandboxed, which is why everything worked for weeks; the store build enforced the rule I had been ignoring. No permission dialog, no entitlement, no setting unlocks it. When I asked Apple directly, the DTS answer was the one at the top of this post: distribute outside the store.¹

A Category Closed Since 2012

The part that makes the wall interesting is who is standing on the other side of it. Magnet, Moom, BetterSnapTool: window tools you can buy on the Mac App Store today. Their listings predate the June 2012 sandbox mandate, so they run unsandboxed under a grandfather clause that transfers to nobody else. Every window manager born after 2012 (Rectangle, Swish, Loop, BetterTouchTool, Amethyst) distributes outside the store. Apple has enforced the line in the other direction too: PopClip, on the store for nearly 13 years, left in March 2024 after review told its developer that new Accessibility-based functionality could not ship in a sandboxed update.³

I want to be plain about my read: the sandbox rule is reasonable. An app that can silently read and move every window on your screen is an app that can surveil you, and “trust me” is not a security model. The store’s promise is that nothing you install there can do that. The unfairness is narrow and specific: incumbents keep an ability that newcomers cannot earn through any amount of user consent. The category was not banned; it was fossilized.

The Turn

The DTS verdict had one flaw: the store already contained counter-examples. Align (2024) and snApp (2023) both tile windows, both live on the Mac App Store, both born long after 2012. snApp is open source, so the mechanism is not a secret; it is a repository.²

The sandboxed app never touches another app’s windows. It drives Shortcuts, Apple’s own automation app, through two declared entitlements:

<key>com.apple.security.automation.apple-events</key>
<true/>
<key>com.apple.security.temporary-exception.apple-events</key>
<array>
  <string>com.apple.shortcuts.events</string>
</array>

Shortcuts, since macOS 12, ships actions named Find Windows, Move Window, and Resize Window.⁵ Shortcuts is allowed to move windows because it is Apple’s. So the app computes where every window should go, hands that plan to a user-installed companion Shortcut, and Apple’s own engine does the moving. The sandbox is never violated, because the sandboxed process never performs the privileged act. Delegation, not permission.

There is something almost architectural about the shape of it: the security boundary stays exactly where Apple drew it, and the capability crosses the boundary by traveling through the one process on the system that legitimately holds it.

The Build-Out

Knowing the mechanism and shipping it are different weeks. The pieces that made it production-real:

Authoring the Shortcut programmatically. Users should not hand-assemble a 12-action workflow. The companion .shortcut file is a binary plist of WFWorkflowActions that the app generates and signs at build time with shortcuts sign -m anyone, so installation is one click into the Shortcuts app. The runtime contract is a JSON payload piped through ScriptingBridge’s shortcut.run(withInput:):

{"app": "Ghostty", "frames": [{"x": 0, "y": 38, "w": 1280, "h": 771}, ...]}

Window identity is z-order. The Shortcut’s Find Windows action indexes windows front-to-back, and CGWindowList enumerates the same order. So payload slot i simply carries the frame for window i, and by assigning cells in position-rank order the grid reproduces “windows stay near where they were.” No window IDs cross the boundary, because none exist on the other side.

Guard rails. An Items in Range clamp bounded by Count keeps a stale payload from indexing past the live window list. A minimum-size filter (120×80) excludes the phantom parked panels that CGWindowList reports and the old Accessibility role-check used to hide. And a fact that surprised me: window listing requires no permission at all; CGWindowList is sandbox-legal. Only moving was ever forbidden.

One codebase, two engines. The app detects the sandbox at launch via the APP_SANDBOX_CONTAINER_ID environment variable. Store builds tile through Shortcuts; Developer ID and development builds use the direct Accessibility path. Same UI, same math, different mover.

Watch mode without notifications. The opt-in auto-retile feature would normally subscribe to Accessibility window notifications, which the sandbox also removes. It survives as window-server polling: cheap CGWindowList diffs, retile on change.

The Cost, Stated Honestly

The user pays a one-time setup tax: install the companion Shortcut (one click) and grant one automation consent dialog (the standard “941 Tiles wants to control Shortcuts” prompt, localized in all 17 languages via InfoPlist.xcstrings). After that the experience is identical to a direct-API tiler: click the grid icon, click an app, windows land. The Shortcuts run is invisible and takes well under a second.

I will not pretend the tax is nothing; it is one more screen than Magnet shows. It is also the entire price of existing inside the sandbox rather than asking users to bypass Gatekeeper for a notarized download they have no reason to trust yet.

The Payoff

The same Intel Mac that had failed five store builds: install, shortcut setup, consent, and four scattered Ghostty windows snapped to exact quadrant frames in 0.6 seconds on the first run. Then the internationalization pass (String Catalogs, CLDR plural rules including all six Arabic categories), the localized listing, and submission. After one review rejection and a ~30-minute re-review, 941 Tiles is live: $4.99 one-time, macOS 15+, 17 languages, zero data collection, no network access.

What Generalizes

The pattern is bigger than window tiling. When a platform closes a capability behind a boundary, the answer is rarely to fight the boundary; it is to inventory which first-party processes already hold the capability and expose a sanctioned interface to it. On macOS that inventory increasingly points at one place: Shortcuts, which has quietly become the system’s privileged-automation broker, reachable from inside the sandbox by design. My Shortcuts guide covers that surface in depth, and the 941 Tiles case study walks this same story with the architecture diagrams.

The sandbox did its job. The app shipped anyway. Both of those sentences are true, and the door between them was Apple’s own.