WhichSpace puts your macOS Spaces in the menu bar

A menu bar item for the thing macOS hides

macOS Spaces are easy to create and easy to lose track of. WhichSpace exists to answer one narrow question, which space am I on right now, and to make the answer clickable.

The app is a menu bar utility written in Swift for macOS 14.0 and later. It can show only the currently active Space or every Space at once, and the menu bar icon doubles as a switcher. Clicking a Space jumps to it, and scrolling over the icon cycles through them. A separate action sends the front window to another Space, which is the operation that saves the most time when a window belongs somewhere else.

Two presentation defaults are worth knowing before you start clicking around. Inactive Spaces are dimmed, and empty Spaces can be hidden entirely. Both are configurable, since the whole app is organised as a set of per Space appearance options rather than a single switch.

The repository layout matches a normal Xcode project: WhichSpace.xcodeproj, a WhichSpace source directory, a WhichSpaceTests directory, a Vendor directory, a Package.resolved for Swift package dependencies, and a Makefile that wraps the xcodebuild commands.

One menu bar item means one display cannot be labelled

The limitation the documentation is most upfront about is the display story. macOS allows an app only one menu bar item, mirrored on every display, so WhichSpace cannot show a different number on each monitor. What the setting does instead is draw every display's Spaces into that single item, with a vertical separator between displays.

This is a platform constraint rather than a shortcut the developer took, and it shapes what the menu looks like on a multi monitor desk. The alternative would be a separate menu item per display, which macOS does not allow for a normal app.

Full screen apps get their own treatment in the same menu. They are shown as their app icon, or as the letter F, and they can be hidden entirely. That is a practical detail, because a full screen window in another Space will otherwise show up as an anonymous entry with no number to click.

The other multi display caveat is about Space ordering. The documentation advises turning off Automatically rearrange Spaces based on most recent use under System Settings, Desktop & Dock, Mission Control, because macOS moves the Space you switch to towards the front on every switch. WhichSpace keeps each Space's colours, icon and label with it either way, so the customisation survives the reordering even when the order does not stay put.

Per Space colours, icons, symbols, badges, labels and fonts

The bulk of the settings is per Space appearance, and the interesting part is that each attribute can also be applied to all Spaces at once. Colours set a foreground and background per Space. Icons come from a set of shapes including square, circle and triangle. Symbols use native macOS symbols instead of numbers, and emojis are offered as an alternative.

Labels replace the Space number with your own text, and the syntax includes a placeholder. Using {#} in a label inserts the current Space number, so a label of {#} - Work becomes 3 - Work. Badges work the same way with a single character next to the number, where # inserts the current number. Size scales the icons and their padding in the menu bar, and a custom font can be set per Space.

The practical payoff is that a labelled, coloured Space is identifiable at a glance from the corner of the screen, which is exactly what a number alone is not. Whether that is worth the configuration depends on how many Spaces you actually run.

The same per Space versus all Spaces pattern applies to everything in this settings area, which makes bulk edits straightforward and leaves room for one Space to stand out.

Installing through Homebrew or the release zip

The recommended installation path is the Homebrew cask:

brew install --cask whichspace

The alternative is to download the release archive from GitHub and run the app directly. The instructions are to download WhichSpace.zip from the latest release, extract it and run WhichSpace.app.

The release route points at WhichSpace.zip in the latest release download path, and the documentation notes that future updates are handled automatically once the app is installed this way. The app also offers launch at login and auto-updates as built-in settings, and it is translated into multiple languages.

Building from source is handled through the Makefile, which wraps xcodebuild. The default deployment target is set by the variable MACOSX_DEPLOYMENT_TARGET, defaulting to 14.0, and the build configuration defaults to Debug. The default target runs clean, format, lint and test in sequence. There is a run target that kills any running copy, rebuilds into a dedicated DerivedData directory and opens the app, which exists so that rebuilding never rewrites the bundle the running app was launched from.

Signing is handled through an optional WHICHSPACE_CODE_SIGN_IDENTITY variable, and a RELEASE variable switches the build configuration to Release.

Keybinds, sounds and a user sounds folder

Global keyboard shortcuts can switch Spaces or move windows between them. Two distinct behaviours are documented for the window shortcuts. Send leaves you on the current Space while Move follows the window to its new one, so you can park a window without leaving your own workspace.

Sounds are also configurable. You can pick from the built-in macOS system sounds or add your own, and the custom sound route is a filesystem convention rather than a settings screen. Creating the ~/Library/Sounds directory if it does not exist and copying a sound file into it makes that file appear under the User section of the Sound menu. That is the standard macOS mechanism, used here rather than reinvented.

Together with click-to-switch and scroll-to-switch, the input options cover the three habits people have: clicking, scrolling and a keyboard shortcut, with the keybinds covering the case where you want to reach a specific Space without touching the menu.

Shortcuts, AppleScript and the whichspace:// URL scheme

This is where WhichSpace is more than a status indicator. It registers native actions in the macOS Shortcuts app, so you find them by searching for WhichSpace there. The action list covers switching to a Space by number, switching left or right one Space, switching back to the previously visited Space, moving the front window to a Space by number with an option to follow it, moving the front window one Space in either direction, reading the current Space number, label or badge into a shortcut, applying or resetting a label or badge on the current Space, and resetting every Space label or badge at once. Switching Space and reading the current Space number are also reachable from Spotlight and Siri.

AppleScript exposes the same state through space and display objects. Setting a label or badge to an empty string resets a single Space, and the reset all space labels and reset all space badges commands mirror the Reset All actions in the interface.

There is also a URL scheme, which the documentation lists as control via whichspace:// links. That gives you a third way in, useful for a browser, a note, or anything else that can open a URL.

The pattern is consistent across all three: the Shortcuts actions, the AppleScript dictionary and the URL scheme all read and write the same per Space label and badge state, so a script can set a label once and the menu bar reflects it.

A small Swift codebase with linting wired into make

The engineering setup is worth a look if you maintain Swift projects, because the tooling choices are visible in the repository root. There is a .swiftlint.yml for SwiftLint, a .swiftformat file for swiftformat, a .repignore file, and a Makefile with dedicated targets for each step. The check target runs swiftformat in lint mode. The lint target runs swiftlint with the strict flag and validates the scripting definition file with xmllint, which is how the AppleScript interface stays in sync with the code.

The formatting target is a chain: clover format, rumdl for Markdown, then swiftformat. The fix target runs swiftlint with the fix flag on top of formatting.

For releases, the Makefile derives a version stamp from git describe, producing something like 1.2.0-18-g6d9e2c7-dirty, and the run target passes it to the build as MARKETING_VERSION. That is how a development build carries a version that says exactly which commit it came from.

The test target runs xcodebuild test against the WhichSpace scheme, and there is a WhichSpaceTests directory alongside the app. On licensing, the repository carries an MIT licence, which is permissive and uncomplicated for most use, though any specific question about it belongs with your own counsel.

Released regularly, with a nightly build alongside the tags

The repository is not archived and the last push was on 2026-10-18. The release history shows a fast cadence near the present: v1.4.2 on 2026-10-17 and v1.4.1 on 2026-10-13, alongside a nightly build tagged tip on 2026-10-17.

A tip tag next to numbered releases is a signal about how the project works. There is a stable line you can pin, and there is a nightly artefact for anyone who wants the newest behaviour and accepts that it can change.

For a menu bar utility, that matters less than it would for a library, because there is no API surface to break. A user who wants stability takes v1.4.2 and waits; a user who wants a specific new behaviour takes the nightly build. The Homebrew cask is the simpler route for most people, and the app also updates itself once installed.

The one upgrade cost worth planning for is the macOS floor. The deployment target is 14.0 in the Makefile and the description states macOS 14.0 and later, so on an older machine there is nothing to install.

Editorial conclusion

WhichSpace is worth installing for anyone who runs several macOS Spaces and wants the active one visible at a glance, or who wants to script Space switching without a third party automation layer, since the Shortcuts actions, AppleScript dictionary and whichspace:// URL scheme are all documented. It is not useful on macOS 13 or earlier, because the deployment target is 14.0, and it cannot show per display information, since macOS allows an app only one menu bar item. Before installing, run brew install --cask whichspace, then check whether you want the item to show every Space or only the active one, and whether the Spaces on your machine rearrange themselves under the Mission Control setting the project calls out.

Frequently asked questions

Official sources

1. gechr/WhichSpace on GitHub
2. Issues
3. License: MIT
4. README
5. Releases