Kolibri is a small Mac utility. You hold fn and ctrl, move the mouse, and the window under the pointer follows. Add Option and it resizes from the nearest corner. It's the Alt-drag that Linux desktops have had forever, and I missed it every day on the Mac.
Utilities like this have always been built on the Accessibility API. You ask the system for the window under the pointer, then set its position as the mouse moves. It works well. It also can't ship in the Mac App Store, because the Accessibility API doesn't work in the sandbox, and every App Store app has to be sandboxed. That's why Moom 4 is sold only from Many Tricks' own site. The Moom that's still in the store is Moom 3, now called Moom Classic. It got in before the sandbox rule and may stay as long as it gets no new features.
I wanted Kolibri in the store anyway. Most people look for Mac apps there, and I didn't want to build my own payment system. This is how it went.
What a sandboxed app is allowed to do
A sandboxed app can't touch another app's windows. It can, with the right entitlement and the user's permission, send Apple Events to other apps. One of the apps it can talk to is Shortcuts, and Shortcuts has actions called Find Windows, Move Window and Resize Window. They run inside Shortcuts, with Shortcuts' own permissions, outside my sandbox.
I didn't figure this out myself. snApp, a window snapping app in the Mac App Store, already ships a shortcut that uses those actions. I read its shortcut file to learn the format.
So the App Store build of Kolibri works like this:
- While you hold the keys, Kolibri draws its own outline and moves that outline with the mouse. The real window stays where it is.
- When you let go, Kolibri sends one Apple Event to Shortcuts Events. The event runs a shortcut called "Kolibri Window Mover" with a small JSON payload: the app's name, which of its windows it is, and the new frame.
- The shortcut reads the payload, finds the window with Find Windows, and places it with Move Window and Resize Window.
The Apple Event is one line of AppleScript:
tell application "Shortcuts Events" to run shortcut "Kolibri Window Mover" with input "{\"app\":\"Safari\",\"i\":1,\"x\":0,\"y\":38,\"w\":1280,\"h\":771}"The only entitlements beyond the sandbox are the Apple Events entitlement and a scripting target for Shortcuts Events that allows running shortcuts and nothing else. The user sees one Automation prompt the first time they move a window.
The shortcut itself is generated by a Python script in the repo and
signed with shortcuts sign --mode anyone. Shortcuts on
the Mac won't import an unsigned shortcut file, and the "anyone" mode
lets anyone import it. The signed file ships inside the app. On first
launch Kolibri runs shortcuts list, and if the shortcut
isn't there it opens the file, and Shortcuts shows its normal import
sheet. That's one click for the user.
The rejection
The first build I submitted was rejected on September 2, under guideline 2.4.5 for using Accessibility and under 2.3.3 for the screenshots.
The window moving already went through Shortcuts in that build. What triggered the rejection was how I followed the mouse and read the keys: a CGEvent tap, which needs Accessibility permission. So the app asked for Accessibility, and a window tool that asks for Accessibility gets rejected, whatever it does with it.
The fix was to stop needing it. The App Store build now follows the pointer with a standard global mouse-moved event monitor and reads the modifier keys from the system's current flag state. Neither needs Accessibility or Input Monitoring. I removed the tap, the permission check and the menu item that asked for it, and replaced the screenshots with unedited captures of the outline in the middle of a drag. The second submission passed.
What it costs
The window lands 200 to 330 milliseconds after you let go. That's the round trip through Apple Events and Shortcuts, and there's nothing I can do about it. It's why the App Store build shows an outline instead of the window itself while you drag. Moving the real window through Shortcuts on every mouse event would be far too slow.
Shortcuts also finds the window by app name and window order, not by a handle. That's reliable in practice, but it's a guess compared to what Accessibility gives you.
And in click mode, where you hold the keys and click to start a drag, the App Store build can't swallow the click, because that also takes an event tap. The click reaches the window underneath.
Two builds
The outline is a decent compromise, but it isn't the app I set out to make. So there are two.
The App Store version is the one described above. Kolibri Pro is a separate download from this site, signed with Developer ID, notarized and not sandboxed. It uses Accessibility and moves the real window live, with its contents visible, as the original Kolibri did. It needs no shortcut and no Automation prompt.
Pro is free for anyone who bought the App Store version, and it has no license keys, accounts or server. On launch, Pro finds the App Store copy of Kolibri on the same Mac and checks its receipt offline:
- The receipt's signature must chain to Apple's root certificate, which Pro carries itself instead of trusting the system store.
- The receipt must name the App Store app's bundle ID.
- The receipt's hash must match this Mac's hardware ID, so a copy brought over from another Mac doesn't unlock it until the App Store downloads it again.
If any of that fails, Pro says why, offers to open the App Store and quits. The App Store handles payment and refunds, and people who want the live version still get it. Both builds come from one Xcode project. They share the pointer tracking, the keys, the preferences and the menu bar, and differ in the part that moves the window.
The idea of shipping two builds came from listening to John Siracusa on ATP.
Both builds are side by side on video in the press kit.