KeyboardShortcuts

The observer in runs on every pass of the run loop and each pass calls . This is expensive: it triggers a CoreAnimation commit and full layout pass. Here is a sample taken while hovering over a menu: The upshot is that the menu's highlight lags behind the cursor. Separately, every re-posted mouse-moved event is expensive. While hovering, I could get my CPU to spike to 50% (M5 Pro). One solution is to gate the observer callback with a call to and exit early if the counter hasn't incremented: There is a side-effect though: the counter doesn't increment while a menu _within the hosting app_ is open. In other words, you can't activate the shortcut while a menu in your own app is open. See https://github.com/jamdotdev/KeyboardShortcuts/tree/menu-performance

PRs are restricted to collaborators on this repo, so I'm filing this as an issue. Fixes are pushed to my fork and linked below — happy for them to be cherry-picked, or I can open a PR if you'd rather grant access. On macOS 26/27 the recorder is unusable: clicking the field focuses it, but pressing a shortcut types a character into the search field instead of recording it. ⌥⇧P inserts . The clear button does nothing at all. There are three independent defects that compound — each fix only changes the symptom, which is what made this hard to pin down. All three reproduce in a ~100 line SwiftUI app using nothing but this package, so it isn't app-specific. Verified on both 0.7.1 and 3.0.1. 1. holds its monitor token weakly https://github.com/ppardi/KeyboardShortcuts/commit/c3f86c6 returns an autoreleased object the caller must own until it's passed to . Held weakly, nothing retains it, so it's deallocated when the autorelease pool drains at the end of the current event-loop turn. arms its key monitor inside , so the monitor is gone before the user can press anything. The field looks focused and captures nothing. is unreachable for the same reason — it early-returns on a nil , so monitors are never removed either. Present since c5d135b (2021), evidently masked until now by AppKit keeping the token alive internally. 2. ends the recording session it just started https://github.com/ppardi/KeyboardShortcuts/commit/3f517c0 does this, in order: Mutating while the field editor is installed makes AppKit end and restart editing. The resulting calls unconditionally, and it can land after the monitor is armed — tearing it down microseconds later. The failure tracks the field's contents exactly, which is what makes it look random: field already holds a shortcut → → cell mutates → editing ends → monitor dies field empty → , already nil → no mutation → monitor survives So recording works on a cleared field and fails when replacing an existing shortcut. Clearing the field or refocusing appears to "fix" it because both leave it empty for the next focus. Trace — failing, then working: ``blur()` after a successful capture, so the user can keep trying combinations without clicking back in. That one is a UX preference, not a fix — it's deliberately last so the three fixes can be taken without it. Tested on macOS 27.

We should migrate the with that may be rolled out with PR #210 If you don't mind, I would offer to migrate the other s, but in a different PR. So it's clean and easy to follow. _Originally posted by @Maschina in https://github.com/sindresorhus/KeyboardShortcuts/pull/210#discussion_r2072461372_