FlashSpace: a macOS workspace manager that swaps Spaces for hotkeys

The problem FlashSpace targets: macOS Spaces are slow to switch

Native macOS Spaces are tied to the system animation. FlashSpace's README frames the project as something designed to "enhance and replace native macOS Spaces", with the explicit complaint that you end up waiting for animations. That is a narrow problem, and the project treats it as narrow on purpose: its stated values include a UNIX-philosophy line about doing one thing well, namely managing workspaces.

The audience is therefore specific. You are a macOS user with more than one display, you keep many apps open at once, and you want to jump between groupings of those apps with a keystroke. The README's own usage steps assume you have already consolidated your apps onto a single macOS Space per display, then create workspaces inside FlashSpace and assign apps to each. If you are happy with the native Space swipe and never think about which app lives where, this tool is solving a problem you do not have.

One requirement is easy to miss and it is not optional. The README lists two requirements: macOS 14.0 or later, and "Displays have separate Spaces" enabled in Desktop & Dock system settings. The second one is a system-level toggle that changes how macOS itself behaves, so installing FlashSpace is not a purely additive change.

How the workspace model actually works

The mechanism is hide-and-present rather than virtual desktops in the kernel sense. The README states it plainly: you define virtual workspaces, assign apps to them, and assign each workspace to a specific display. When you switch to a workspace, the assigned apps are presented and all other apps on that display are hidden. There is no compositor trickery described; the app is moving window visibility around.

Two consequences follow from that design. First, workspaces can be switched independently per display, so a switch on your laptop screen does not force a switch on the external monitor. Second, display assignment is a real configuration decision, not an afterthought. FlashSpace offers two modes. Static is the default: each workspace belongs to one named display, which the README compares to how macOS Spaces work, and it notes this mode is awkward if you rearrange displays often. Dynamic assigns a workspace to whichever displays its apps currently sit on, so one workspace can appear on several displays at once, at the cost that empty workspaces cannot be shown.

The same app can appear in more than one workspace. The README gives two routes: the Floating Apps setting, which keeps an app visible across all workspaces, or adding the app to multiple workspaces from the main window. Around the core model sit extras that share the same state: Space Control for a grid preview, a Workspace Switcher on Option + Tab, focus movement hotkeys, a cursor manager, profiles, swipe gestures, and a menu bar item. Configuration is available through the GUI or a config file in JSON, YAML or TOML.

Installing FlashSpace and switching your first workspace

The README gives Homebrew as the primary install path, with a Releases page for a prebuilt binary and a Build From Source section for compiling it yourself. The Homebrew command is one line:

brew install flashspace

Before you run it, turn on "Displays have separate Spaces" in Desktop & Dock and confirm you are on macOS 14.0 or later. The README lists both as requirements, and the display setting is the one people skip.

The README's usage sequence is worth following literally rather than improvising. Move all your apps to a single macOS space per display first. Then create a workspace in FlashSpace, assign apps to it, assign a display to it (or switch to dynamic mode), and set a hotkey. Repeat for your other workspaces. After that, switching is just the hotkey. The README's demo shows three workspaces driven by hotkeys.

If you prefer to keep configuration in a file, FlashSpace accepts JSON, YAML and TOML. The README does not publish a full schema, so the reliable route is to configure through the GUI and read back what it writes rather than hand-authoring a config from scratch. There is also a CLI target in the repository (FlashSpaceCLI) and a Raycast extension credited to krmbzds, both listed in the feature set. The README does not document the CLI's subcommands, so treat the GUI as the source of truth until you read the CLI sources.

Picture-in-Picture, the workaround, and its English-only caveat

FlashSpace's PiP handling is the clearest example of a feature built around a macOS limitation rather than on top of an API. The README explains that macOS offers no public API to hide a single window, and hiding the whole app also hides the PiP window. The workaround FlashSpace uses is to detect whether the app supports PiP and then hide every window except the PiP window in a screen corner. If the PiP window is not visible, standard behaviour applies.

This is labelled experimental and can be turned off in App Settings, Workspaces. The supported browser list is explicit: Safari, Zen Browser, Chrome, Firefox, Brave, Vivaldi, Arc, Dia, Opera, Microsoft Edge and Comet. The README adds a blunt warning that the feature may not work if your browser language is not set to English. That is a hard constraint on a feature that only matters to people who watch video in a corner while working, and it is the kind of thing you want to know before you build a workflow on it.

The honest reading is that PiP support is a compatibility shim. It is not a reason to choose FlashSpace, and the README does not pretend otherwise: the feature is opt-out, experimental, and browser-dependent.

Where FlashSpace is the wrong choice

The design assumes a stable display topology in its default mode. Static assignment ties each workspace to a specific display, and the README itself says this mode can be challenging when you use multiple displays and change their arrangement frequently. If your setup is a laptop that docks and undocks several times a day with different monitors attached, static mode will fight you, and dynamic mode has its own trade-off: you cannot show an empty workspace. There is no described third option that gives you both fixed placement and tolerance for rearranged displays.

Second, FlashSpace replaces the workflow, not the system. It does not remove native Spaces; it asks you to consolidate apps onto one Space per display and let FlashSpace do the switching. Anyone who depends on native Spaces for other reasons, or who shares the machine with people who use the standard macOS gestures, is signing up for a configuration that only makes sense inside FlashSpace.

Third, the documentation is uneven. The README describes features and gives a SketchyBar integration example, but it does not document the CLI surface, a config file schema, or a rollback path if a workspace configuration goes wrong. You are relying on the GUI and on the app's own behaviour to tell you what a valid config looks like. That is workable for a personal tool and frustrating if you want to manage configuration across several machines.

FlashSpace versus AeroSpace and the tiling approach

The most common comparison people search for is FlashSpace versus AeroSpace, and the difference is architectural rather than cosmetic. AeroSpace and similar tools (the related searches also surface skhd and Paneru) belong to the tiling window manager family: they take over window placement and arrange windows into layouts. FlashSpace does not tile. Its README describes assigning apps to workspaces and hiding everything else on the display; window geometry is not the subject.

That distinction decides the choice. If you want windows to be arranged automatically into columns and rows with keyboard-driven resizing, a tiling manager is the right category and FlashSpace will not do it. If you already manage window size and position yourself and only want instant, hotkey-driven grouping of apps across displays, FlashSpace targets exactly that, and a tiling manager would be extra machinery you did not ask for.

The two can coexist in principle, since FlashSpace's stated scope is workspace management alone, but the README does not describe an integration with any tiling manager and does not claim one. Treat them as separate layers and expect to test the combination yourself.

Maintenance, licence and the cost of upgrading

The repository is not archived, and the last push was on 2026-09-17, days before this article. Releases are frequent and versioned in a four-part scheme: v4.18.79 on 2026-09-07, v4.17.78 on 2026-05-20, v4.16.76 on 2026-04-28. The repository contains a sparkle/ directory, which is the Sparkle update framework for macOS, so the app is set up to update itself rather than requiring a manual reinstall each time. The README does not describe a downgrade procedure, and given the pace of releases, keeping a copy of the release you are running is sensible before you move to a newer one.

Licensing is GPL-3.0. For individual use on your own Mac that is unremarkable. It matters if you intend to fork FlashSpace, ship a modified build, or bundle it into something distributed, because GPL-3.0 carries source-disclosure obligations for derivative works. This is not legal advice; read the LICENSE file in the repository and take advice if you plan to redistribute.

The upgrade cost is mostly configuration drift. The README documents configuration through both the GUI and a config file, and it does not publish a schema or a migration guide, so a release that changes a config key will not announce itself in the documentation. If you keep your workspaces in a file, keep it under version control so a diff tells you what changed.

Editorial conclusion

Adopt FlashSpace if you run macOS 14 or later, keep your apps on a single native Space per display, and want workspace switching bound to hotkeys rather than the Space animation. Skip it if you rely on native Spaces as your primary organisation, if you change display arrangements often and do not want to reason about static versus dynamic assignment, or if non-English browser UI matters to you because the Picture-in-Picture workaround depends on English. Before committing, verify the Displays have separate Spaces setting, confirm your display arrangement under static mode, and check whether your browser is on the supported PiP list.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. wojciech-kulik/FlashSpace on GitHub