If you use macOS Spaces heavily, you know the tax. Every workspace switch costs you roughly 300 milliseconds of animated sliding, and while that sounds trivial, it compounds fast across a workday. More than the time, it’s the interruption: your eyes track the animation, your mental context briefly fragments, and you arrive at the destination a little less sharp than when you left.
Arhan’s post on native instant space switching tackles this by going directly to the macOS window server’s private API layer rather than routing through the public interfaces that force the animation. The technique is cleaner than most workarounds that have circulated over the years, and it illuminates something broader about how macOS actually manages virtual desktops.
The Long History of Workarounds
People have been trying to eliminate space switching animations since Spaces launched in Mac OS X Leopard. The earliest hack was a defaults write command targeting the Dock:
defaults write com.apple.dock workspacesSwooshAnimationOff -bool YES && killall DockThis worked on older versions of macOS but stopped being reliable around Mountain Lion. The underlying preference still exists in some forms but the Dock no longer honors it consistently on modern releases.
The Reduce Motion accessibility setting (System Settings > Accessibility > Display) does eliminate the slide transition, replacing it with a cross-fade. For many people this is good enough, but it’s a blunt instrument that modifies animations across the entire system, including things like window minimization and application transitions. You’re not opting out of the space animation; you’re changing the physics of your entire desktop.
TotalSpaces2 by BinaryAge was the gold standard for serious Spaces power users for years. It gave you a grid layout, instant switching, and configurable transitions. But it relied on injecting code into the Dock process via a mechanism that required partially disabling System Integrity Protection (SIP), and Apple’s security hardening in macOS 11 and later made that increasingly fragile. The app is effectively dead on modern Apple Silicon systems running current macOS.
yabai, the popular tiling window manager, takes a similar approach. Its space manipulation features, including moving windows between spaces and focusing specific spaces, use the same private CGS (CoreGraphics Services) layer. The yabai documentation explicitly states that space management requires SIP to be partially disabled. On Apple Silicon this means booting into recovery mode, running csrutil enable --without debug --without fs, and accepting the reduced security posture permanently.
AeroSpace by Nikita Bobko took a different design decision entirely: rather than manipulating spaces, it manages windows within a single space using a virtual layout. All your “workspaces” in AeroSpace terms are actually windows on one macOS space, rearranged and hidden as needed. This avoids any dependency on private APIs or SIP modifications, but the trade-off is that macOS Mission Control and other system features see a very different picture than you do.
What the CGSPrivate Layer Is
All of these tools, one way or another, brush up against a set of functions that Apple ships but does not document: the CoreGraphics Services private API, commonly accessed through a reverse-engineered header file called CGSPrivate.h.
CGS sits between the public CoreGraphics framework and WindowServer, the system process that owns the display. When you call NSWindow methods or use CoreGraphics drawing functions, you’re eventually talking to WindowServer through the CGS connection layer. The public API surface covers most of what most apps need. What it doesn’t expose is direct workspace manipulation.
The connection entry point is straightforward:
// Reverse-engineered declarations, not in any public header
typedef int CGSConnectionID;
typedef uint64_t CGSSpaceID;
extern CGSConnectionID CGSMainConnectionID(void);
extern CGSSpaceID CGSGetActiveSpace(CGSConnectionID cid);
extern NSArray *CGSCopySpaces(CGSConnectionID cid, uint32_t mask);The function that actually moves you between spaces is:
extern void CGSSetWorkspaceWithTransition(
CGSConnectionID cid,
CGSSpaceID workspaceID,
int transitionType,
int options,
float duration
);Passing 0 for transitionType and 0.0 for duration produces an instant switch with no animation. The WindowServer processes the request synchronously and your display updates on the next vsync. No slide, no fade, no interruption.
A minimal working example in Swift, using a bridging header to expose the C declarations:
// BridgingHeader.h
#import <CoreFoundation/CoreFoundation.h>
typedef int CGSConnectionID;
typedef uint64_t CGSSpaceID;
CGSConnectionID CGSMainConnectionID(void);
CGSSpaceID CGSGetActiveSpace(CGSConnectionID cid);
NSArray *CGSCopySpaces(CGSConnectionID cid, uint32_t mask);
void CGSSetWorkspaceWithTransition(CGSConnectionID, CGSSpaceID, int, int, float);func switchToSpace(_ spaceID: CGSSpaceID) {
let cid = CGSMainConnectionID()
// transitionType: 0 = none, duration: 0.0
CGSSetWorkspaceWithTransition(cid, spaceID, 0, 0, 0.0)
}
func listSpaces() -> [CGSSpaceID] {
let cid = CGSMainConnectionID()
// mask 1 | 2 covers both user spaces and fullscreen spaces
guard let spaces = CGSCopySpaces(cid, 3) as? [CGSSpaceID] else { return [] }
return spaces
}The CGSCopySpaces mask values are themselves undocumented, reverse-engineered from WindowServer behavior. The value 1 covers standard user spaces, 2 covers fullscreen app spaces, and 4 covers the System UI space. Most tools use 7 (all three) or 3 to get the spaces a user would actually want to navigate between.
The “Native” Distinction
The word “native” in the article title is doing meaningful work. Plenty of tools achieve instant switching by other means: sending synthesized keyboard events (Ctrl+1 through Ctrl+9 via CGEventPost), using the Accessibility API to target the Dock’s space switcher, or even simulating trackpad swipes. These approaches work but they’re indirect: you’re triggering the same code path that the animation runs through, just hoping to shortcut it somehow.
Calling CGSSetWorkspaceWithTransition directly with zero duration bypasses that code path entirely. The WindowServer switches the active space at the compositor level. There’s no keyboard event, no Dock involvement, no Accessibility permission required. The app that makes the call needs to be the frontmost application or have an appropriate entitlement, but it does not need Accessibility access in the same way a keyboard event injector would.
This also means the switching is reliably synchronous. Event injection approaches can have timing issues where a space switch command races against focus state or window activation. The direct CGS call doesn’t have this problem; the switch happens in-process with the WindowServer’s reply.
The Risks and the Entitlement Question
Using undocumented APIs on macOS carries the usual caveat: Apple can change or remove them without notice, and they frequently do. CGSSetWorkspaceWithTransition has survived multiple major macOS versions, but there’s no guarantee it survives the next one. More immediately, apps distributed through the Mac App Store cannot use private APIs; App Store Review will catch them. A tool built on this technique can only ship outside the store, which is fine for developer utilities but limits broader distribution.
The SIP question is worth separating from the API question. The basic space-switching call demonstrated here does not require SIP modification on its own. What requires SIP is manipulating other processes’ windows, such as moving a window from one space to another without that window’s consent. If you only want to switch which space is active, you can do that as your own process without any SIP changes. This is a meaningful distinction from yabai’s requirements.
On macOS Sequoia, some users have reported that CGSSetWorkspaceWithTransition briefly flashes when switching to a space that contains a full-screen app, suggesting Apple’s implementation has changed how that case is handled. The basic case of switching between ordinary desktop spaces remains stable.
What This Reveals About macOS Desktop Management
The fact that power users have spent fifteen years writing blog posts, open-source tools, and kernel extensions to get instant space switching points to a persistent mismatch between what macOS makes easy and what keyboard-heavy workflows require. Apple’s design defaults favor discoverability and visual continuity; the slide animation tells you which direction you moved and confirms the gesture registered. For someone who switches spaces dozens of times per hour by keyboard shortcut, that affordance is pure overhead.
The closest Apple gets to addressing this is the Reduce Motion setting, which is framed as an accessibility accommodation rather than a power-user preference. It’s in the right category functionally but sends the wrong signal: eliminating animations shouldn’t require telling the system you’re photosensitive.
Tools like the one Arhan describes are a workaround for a gap in Apple’s configuration surface. The private API has always been there; WindowServer was always capable of instant switching. The gap is just that Apple never chose to expose the knob.