Filed under debugging logs, since this turned out not to be our bug at all, an iOS routing behavior most people would never think to look for.

Symptom

Building Aiden (drives phones over USB HID, keyboard+mouse emulation, no app on the target device), we hit this: plain letters typed fine every time. Modifier-key shortcuts, Cmd+V, Cmd+A, Shift+X, intermittently didn't register. Our write to /dev/hidg0 returned success on every attempt. Nothing happened on screen.

First real finding

iOS logs distinguish plain keystrokes from modifier-based "key commands" and log the KeyboardFocus target each command resolves to.

Working:

cmd-v -> <keyboardFocus; pid: 9085; token: MobileNotes>

Broken, identical keypress:

cmd-v -> <keyboardFocus; pid: 3738; token: com.apple.springboard>

iOS recognized Cmd+V correctly both times. It just delivered the command to SpringBoard (the home screen process) instead of the actual foreground app. Not an HID-layer failure, a routing failure after the keypress was already understood correctly.

Ruled out (didn't fix it): Full Keyboard Access toggle, Boot Keyboard protocol declaration, LED output handling, keyboard descriptor/handshake sequence, keystroke timing, stale HID file descriptors after re-enumeration.

The A/B that isolated it

With AssistiveTouch left on throughout:

Critical pair: identical keyboard, identical settings, identical test method, keyboard-only vs. keyboard+mouse. Adding the mouse brought the failure back immediately. Removing it: 22/22 clean.

Conclusion: with AssistiveTouch enabled, if iOS detects Pointer/Mouse capability on the connected device at the same time as a keyboard, it can misroute modifier-key commands to SpringBoard. Reproduced on hardware with zero relation to our stack (a standard gaming keyboard, a Bluetooth keyboard), so this rules out an HID-compatibility explanation specific to us. It's a routing bug inside iOS itself, and without source access we can't say why Pointer/Mouse capability affects KeyboardFocus resolution, only that it reliably does.

Also tried substituting a Touchscreen/Digitizer HID class for Mouse/Pointer, keeping pointer: 0. Six Cmd+V attempts, all landed correctly. Supports the same conclusion, but any keyboard interface present still makes iOS hide the software keyboard, and a one-time Eject only recovers briefly, so not viable for our actual product.

Our workaround (not a fix)

Two USB HID profiles with different Product IDs/serials, so iOS doesn't reuse stale device state:

• Normal: keyboard + pointer
• Right before a modifier-key action: re-enumerate keyboard-only, send the keypress, restore pointer after

Switching scope covers a whole agent action, not a single keypress, to avoid the software keyboard popping/retracting repeatedly mid-action.

We're just not letting iOS see the trigger combination during the narrow window it matters.

Full writeup with the complete experiment table: https://aidenai.io/blog/debugging-an-ios-bug-why-command-v-stops-working-with-external-keyboards

Repo: https://github.com/AidenAI-IO/aiden-firmware

If you're driving iOS with an external keyboard + pointer combo and have seen a shortcut silently fail, this might be why.