On macOS, SDL_SetWindowKeyboardGrab behaves inconsistently with Windows (largely ignored on macOS; cannot intercept system shortcuts)
On Windows, calling SDL_SetWindowKeyboardGrab(window, SDL_TRUE) allows an application to intercept/suppress certain system-level key combinations (implemented via a low-level keyboard hook). On macOS, the same code does not prevent system shortcuts from triggering (e.g., ⌘Tab app switching, ⌘Space Spotlight, Ctrl+Arrow for Spaces/Mission Control). This results in inconsistent behavior across platforms and significantly impacts use cases such as remote control, cloud/game streaming, emulators, and kiosk mode.
I'm not aware of a way to prevent this on macOS. I don't think you can turn off Command-Tab in any circumstance. Maybe I'm wrong; if you can think of any app that does, I can take a look at what method it uses.
I tested this code on macOS 26 and it works, provided you grant Accessibility and Input Monitoring permissions. If you have any questions, please contact me.
Proposal: add a hint that, when used with SDL_SetWindowKeyboardGrab, enables “intercept as many key events as possible” to prevent the OS from handling system shortcuts—especially important for games.
UTM can grab system keys like command-tab and command-space. As far as I can see in my settings it doesn't have accessibility or input monitoring permissions and it still works. It doesn't grab touchpad gestures or custom global hotkeys though.
I'll look at what UTM is doing, but I have a suspicion this is a function of Apple Virtualization and probably doesn't work when it falls back to QEMU. Just a wild guess though.
Accessibility is an option, but we'd have to add a hint to request SDL try otherwise-forbidden methods, and apps would have to have code to convince the user to approve permissions. This isn't a dealbreaker, because for certain apps like Remote Desktop, it could be totally reasonable.
This is all likely to slip from 3.4.0 though.
A “fully loaded” UTM-level implementation isn’t necessary. My test code already covers 90% of scenarios; the effort to bridge the remaining 90% to 100% should rightly be borne by developers of software like UTM.
Yeah, @pipiwoaini's solution is dirt-simple, but will definitely have to default to disabled, since it'll need the app to have UI about getting Accessibility permissions, etc. We'll let apps set a hint to request SDL use an event tap to filter these key combos out.
Current plan: I'm going to try to get this in for 3.4.0.
New current plan: I'm going to bump this to 3.6.0. Getting down to the wire, don't want to make big changes and additions at this point.
Waiting for 3.6.0 is a bit too far off. I’ll try to update the code and run some tests when I get a chance, and if everything looks good I’ll submit the changes to move this merge forward
We're going to bump this for now, but if you have a PR in the next week or so we'll consider it for 3.4.