iOS sim: keyboard and hardware buttons still silently no-op on macOS 26.6 + Xcode 27 release (taps recovered) — 0.25.1

[estevg]

Summary

On macOS 26.6.2 + Xcode 27.0 release with Argent 0.25.1, gesture-tap works, but the keyboard tool and hardware button presses still silently no-op: both return success and nothing reaches the simulator.

This is the same failure shape as #932 / #547, but a different slice of it. In #932 taps were dead too; here taps recover and only the key-event channels stay dead — so whatever fixed tap injection did not cover the keyboard/button path. The environment is also different from every report I found: #932 is macOS 27, this is macOS 26.6.2 with the Xcode 27 release, so the regression is not gated on macOS 27.

Environment

macOS       26.6.2 (25G83), Darwin 25.6.0
Xcode       27.0 (27A266a) — release, not beta; DeviceHub.app, no Simulator.app
Argent      0.25.1 (global npm install)
Simulator   iPhone 17 Pro, iOS 26.4, default device set
App         Expo dev client (React Native 0.86.3, Expo SDK 57), Metro connected

What works vs what doesn't

Channel	Result
gesture-tap	Works — taps land, on-screen keyboard keys included
keyboard { text }	No-op — returns { typed: "qa1", keys: 3 }, field keeps its placeholder
keyboard { key: "enter" }	No-op — returns { typed: "enter", keys: 1 }, keyboard stays open
button { button: "home" }	No-op — returns { pressed: "home" }, app stays foregrounded
paste	No-op — returns { pasted: true }, nothing is inserted
describe / screenshot / await-ui-element	Work
Metro CDP (debugger-evaluate, component tree)	Work

Steps to reproduce

1. Boot an iOS 26.4 simulator with boot-device, launch any app with a text field.
2. gesture-tap the field — the software keyboard appears, so focus is real.
3. keyboard { text: "abc" } — returns success.
4. describe — the field still shows its placeholder; no characters were inserted.

Not the app under test

Reproduced identically in Settings.app (com.apple.Preferences): tapping the search field opens the keyboard and switches the screen to "Suggestions" (so the tap landed), then keyboard { text: "wifi" } leaves the field empty. A first-party app rules out the RN app and its SDK version.

Ruled out

• stop-all-simulator-servers (scoped) + simctl shutdown + fresh boot-device — no change.
• Bringing DeviceHub.app to the front before typing — no change.
• Re-tapping the field with the keyboard already open — focus is confirmed by the native "Paste / AutoFill" context menu appearing, and typing still does nothing.
• App reinstall and a full native rebuild.

Confirmation that focus and the pasteboard are fine

Tapping a focused empty field shows the system Paste menu, so the field is focused and empty. Interesting detail: the simulator's pasteboard is synced with the host's, so pbcopy on the Mac followed by tapping Paste does insert the text. That is the workaround I am using to drive a login flow — text entry through taps only:

printf '%s' "user@example.com" | pbcopy   # host clipboard, syncs into the sim
# then: gesture-tap the field, gesture-tap "Paste" in the context menu

Worth noting because it means the paste tool failing is not a pasteboard problem — the pasteboard works; what fails is the key/paste event injection.

Impact

Any flow that types is unrecordable and unreplayable: login screens, search fields, forms. argent-qa-flows cannot produce a passing flow for those paths, since the type: directive rests on the same channel.

[estevg]

Root-caused, and it is the known CoreDevice teardown documented in hid-suppression.ts — not a separate bug. The suppression flag inside my guest reads 1, and the digitizer surviving while buttons and keyboard die is exactly the shape that file predicts for runtimes past 18.6.

What my environment adds is a data point on a runtime the note lists as untested: iOS 26.4 with the Xcode 27.0 release, argent 0.25.1 with the boot warm-up present. 3 of 3 clean boot cycles came up with buttons and keyboard dead, and the background probe emitted no hint on any of them.

Clearing the flag and restarting backboardd revives all three services — verified live: typed text and the home button both landed immediately after.

Opened #1177 with that repair as an explicit revive-simulator-hid tool, which is where the module's own note says it belongs.

[filip131311]

Thank you for testing the work around so soon! I can reproduce the problem and I am working on a permanent solution in order to be as transparent as possible I will write down my findings and progress (and a possible "fix" on the user side) below, if you have any questions what so ever please let me know.

• the issue s in fact caused by the new CoreDevice framework taking over control over communication with simulators in place of Legacy Indigo messges,
• I have found a temporary and flaky workaround that protects the old protocol with a warm up
• I am currently working on supporting the new protocol from core device and while it is difficult I have made some progres over past few days and will keep you updated
• I think you can use argent with no issues if you kill the device hub and just use the older Simulator.app I know it is not ideal, but should help for now

[estevg]

Thanks for looking at this so fast, and for writing down where you are. Knowing a real fix is in progress is worth more than a quick patch.

One correction on the last point, though. On Xcode 27 there is no Simulator.app to go back to. It is not hidden behind DeviceHub, it left the bundle:

$ ls /Applications/Xcode.app/Contents/Developer/Applications/
ls: ...: No such file or directory        # the directory itself is gone

$ open -b com.apple.iphonesimulator
LSCopyApplicationURLsForBundleIdentifier() failed

The bundled apps moved to Contents/Applications/, and DeviceHub.app is what ships there now. So on a machine with only Xcode 27, killing DeviceHub leaves no simulator GUI at all. Anyone still keeping Xcode 26 around can point DEVELOPER_DIR at it and your advice holds, but that is not my case.

What did work here is the recipe your own hid-suppression.ts describes and that 1e466d0 removed: clear the flag inside the guest, then restart backboardd. Typed text and the home button both came back on the first try. I opened #1177 with that as an explicit revive-simulator-hid tool, deliberately out of the boot path, for the reason your note already gives: it kills the foreground app.

It only repairs what is already broken, so it should not get in the way of the CoreDevice work. And if you reach a point where the CoreDevice branch needs testing on 26.4 + Xcode 27.0 release, point me at it and I will run it here and report back.

[filip131311]

Hello @estevg, would you like to try out Argent 0.25.2? I think we found a proper fix 🤞 🤞

[estevg]

Tried it, and yes, it's fixed here.

Same setup as the original report: iPhone 17 Pro on iOS 26.4, Xcode 27.0 (27A266a), CoreSimulator 1171.7, macOS 26.6.2, DeviceHub open. Before testing I checked that the suppression was really on (com.apple.coredevice.dtuhidd.active read 1 inside the guest, dtuhidd running), and I did not run the flag/backboardd repair.

With 0.25.2:

• keyboard typed into the Safari address bar and the text arrived
• button home went back to the home screen
• the flag still read 1 afterwards, so it's the new transport doing the work, not a repair underneath

That's one boot so far; I'll say so here if it ever comes back.

Since universalhid removes the problem instead of patching around it, #1177 has nothing left to do, so I'm closing it. Thanks for the quick turnaround and for keeping the thread updated.