Title: Keyboard shortcut repeat behaves inconsistently after macOS 15.7.7 update (possible IOHIDFamily regression)
BTT Version: 6.663
macOS Version: 15.7.7 (24G720) — regression appeared immediately after updating from 15.7.3 (24G419)
Hardware: MacBook Pro, M1 Max
Describe the bug:
I have two global "Keyboard Shortcut" triggers that remap a modifier+letter combination to arrow-key presses (originally left+right Cmd + W/S, later simplified to single Cmd+W/S and even Ctrl+W/S while troubleshooting — same result regardless of modifier). Both use the predefined action "Send Key Down and Key Up" with keycodes 126 (up) and 125 (down), and have "Repeat assigned action" enabled with Repeat Rate 0.03 and Repeat Delay 0.1.
This setup worked perfectly on macOS 15.7.3. Immediately after updating to 15.7.7, holding the shortcut produces a noticeably slower, "sluggish" repeat compared to a physical arrow key held with system Key Repeat set to minimum — even though the BTT repeat rate/delay values are unchanged and set well below system defaults. Lowering the rate/delay further in BTT made no difference.
Interestingly, the shortcut works correctly (fast, native-feeling repeat) in most third-party apps (Finder, text editors, etc.) — the regression seems isolated primarily to how the emulated repeat "feels" versus real hardware repeat, and additionally I found that navigation using this shortcut inside BTT's own preference window works in some panels (the left app-list sidebar) but not at all in others (the shortcut list / trigger config panels on the right).
Steps to reproduce:
- Create a global keyboard shortcut trigger with a "Send Key Down and Key Up" action set to arrow up/down keycode.
- Enable "Repeat assigned action" with a low rate/delay (e.g. 0.03 / 0.1).
- On macOS 15.7.3: hold the shortcut → smooth, fast repeat.
- On macOS 15.7.7: hold the same shortcut → visibly slower/inconsistent repeat, unaffected by further lowering rate/delay in BTT.
Screen recordings:
When navigating with arrow-keys the sluggishness is gone; it's just when using (left cmd+right cmd+w/s).
Possible cause:
I looked through Apple's security notes for 15.7.7 and noticed two changes specifically in IOHIDFamily (the framework underlying synthetic HID/keyboard event posting, which BTT relies on for its keyboard shortcut actions):
- A memory corruption fix "addressed with improved locking"
- A logging fix related to kernel memory handling
I don't have visibility into BTT's internals, so I can't confirm this is the cause, but the timing lines up exactly with the update, and IOHIDFamily is the layer BTT's synthetic keystrokes pass through. It's also possible this relates to the difference between genuine "Key Repeat" events (with isARepeat set) versus BTT sending repeated separate "Key Down" events — if 15.7.7 changed how these are queued/delivered, that could explain why some UI controls (which may check the repeat flag) react differently than plain text fields.
Flagging this in case it's useful — happy to test any debug builds or provide more logs/recordings if it helps track down.