SwiftShift: a small macOS window mover with quadrants and a pay-what-you-want licence

A window mover that keeps out of the menu bar

SwiftShift describes itself as sweet window management for macOS, and the feature list is short enough to state in full, which is unusual for a window management tool. It can launch at login, hide its menubar icon, focus on window, do smart resizing with quadrants, and ignore custom apps. The menubar icon point deserves emphasis because it is the thing that usually makes a utility annoying. Most macOS helpers of this kind live permanently in the menu bar, and after a week you have stopped seeing them, which means you have also stopped using them. A tool that hides the icon entirely and responds to a shortcut is a different proposition. The ignore custom apps option is the other half of the thinking: some applications manage their own windows, and a window mover that fights with them produces chaos rather than convenience. The project topics name accessibility, appstore, bettertouchtool and macos, and that bettertouchtool tag is telling, because it places SwiftShift in the same category as the automation utility macOS users reach for when they want to bind actions to gestures or hotkeys. The homepage is swiftshift.app, and the source is under the MIT licence.

Four install paths, and only some of them are free

The installation section lists several ways in, and they are not equivalent. You can buy it at swiftshift.app, and the wording there is pay what you want, so the price is not fixed by the author. You can install it with Homebrew using the cask named swift-shift, via the command `brew install --cask swift-shift`.

You can download the latest release from GitHub. And you can clone it and build it yourself. The last two routes are the ones that determine the licence story. The repository is MIT licensed, so the code is open, and the README states the MIT License plainly. That means the distinction you are making is between buying the packaged, notarised app from the author and building the open source yourself. What the source does not give you is a signed and notarised binary, and the release section explains why that is work. Building from source means running the local build, and the README notes that Xcode requires care around signing, pointing at an issue comment about it. The accessibility permission is a related concern that the README handles explicitly for local builds, which is the subject of a later section here.

make run builds unsigned and launches a separate dev app

The command line build is a single target:

make run

The Makefile shows what that actually does, and it is worth understanding because it explains the developer experience. The run target depends on build and run-app. The build target calls xcodebuild with the Swift Shift scheme, setting the SYMROOT to a build directory in the project root, and it explicitly disables code signing with an empty CODE_SIGN_IDENTITY, CODE_SIGNING_REQUIRED set to NO and CODE_SIGNING_ALLOWED set to NO. The run-app target then opens the Debug application from that build directory, named Swift Shift Dev.app. So a local build gives you an unsigned Debug app with a different bundle name, which is the second half of the permission story below. The same Makefile also provides a test target that runs xcodebuild test against the SwiftShiftTests scheme on the macOS destination with code coverage disabled, an appcast target that runs a script to generate the appcast, a generate-keys target running another script, and a release target that runs scripts/release.sh with the version passed in. The catch-all % rule at the end of the file is a no-op, which is a common trick to stop make from complaining about unknown goals.

Local builds use a separate app identity so permissions do not clash

This is the detail that will save you an afternoon if you are going to build and install. The README explains that local Debug builds use a separate app identity, Swift Shift Dev with the identifier com.pablopunk.Swift-Shift.dev, so they can coexist with the released app without reusing the same Accessibility permission entry. On macOS, Accessibility permission is granted per application identity, which means a Debug build with a different identifier appears as a separate entry in the privacy settings. Without that separation, granting permission to the debug build would either fail or silently apply to the wrong app, and the symptom is a window mover that appears to do nothing. The released app and the dev app therefore sit side by side with independent permissions, which is the correct arrangement for anyone who both uses the app and works on it. The same identity distinction is visible in the repository layout, with a Swift-Shift-Info.plist at the root next to the Xcode project directory Swift Shift.xcodeproj, the application source in Swift Shift/, a SwiftShiftTests/ directory, and ExportOptions.plist for the export step.

Releasing means notarising, stapling and publishing an appcast

The release process is the most interesting part of the repository for anyone who wants to understand how a small macOS app gets to users. The setup is one-time: generate an app-specific password at Apple's site, then store the notarization credentials in your keychain with one command:

xcrun notarytool store-credentials "SwiftShift" --apple-id YOUR_APPLE_ID --team-id YOUR_TEAM_ID

That command prompts you to paste the app-specific password. After that, a release is a single command:

make release VERSION=0.28.0

The README enumerates what this does: it bumps the version, archives, exports, notarizes, staples, generates the appcast, creates a branch, commit and tag, opens a pull request with auto-merge, creates a GitHub release with the zip attached, and updates the Homebrew cask automatically. The last step depends on an environment variable. If GH_PAT is available, the release script uses it to push the Homebrew tap update to pablopunk/homebrew-brew. The appcast at the root of the repository, appcast.xml, is the file that makes updates work for people who downloaded the app outside the Homebrew cask, and the generate-keys target exists to produce the keys that appcast feed is signed with. This is a complete, automated release pipeline, and it is a strong argument for installing the cask rather than downloading the zip, since the cask path keeps the update channel consistent.

The website is a separate project with its own toolchain

The marketing site is not part of the Xcode project, and the README keeps it in its own section for that reason. It lives in the www/ directory, it is deployed by Vercel with the Root Directory set to www, and it is developed with Bun:

cd www
bun install
bun run dev

The repository root also carries a .nojekyll file, which tells GitHub Pages not to run Jekyll over the published content, plus a www/src/images directory referenced by the screenshots in the README, one for dark mode and one for light mode. The separation of the site from the app is a small but useful architectural fact: the site can be restyled or rebuilt without touching the Swift code, and the app's release pipeline does not depend on the site being up. There are also directories for assets/, scripts/, a skills/ folder, an .agents/ directory and a .github/ directory, and the appcast.xml, ExportOptions.plist and FIXES.md files at the root. The FIXES.md file suggests a running list of known issues, which is worth a look before you decide the tool is broken rather than in development.

Editorial conclusion

SwiftShift suits a macOS user who wants a keyboard-driven window mover that does not clutter the menu bar, who is willing to install a small helper app and grant it Accessibility permission, and who is comfortable with a project whose distribution runs through an appcast and notarisation. It is the wrong choice if you need a full tiling window manager with workspaces and layout persistence, and it is the wrong choice if you want a signed, notarised binary without doing the release work yourself, since building locally means an unsigned Debug build with a separate app identity. Verify first that the version you install matches the release you read about, that the Accessibility permission is granted to the right app identity, and that the Homebrew cask and the appcast point at the same build.

Frequently asked questions

Official sources

1. License: MIT
2. pablopunk/SwiftShift on GitHub
3. Project website
4. README
5. Releases