You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
axe drag fails on Xcode 26.5: FBSimulatorHIDEvent does not support touch move events #59
Error: CLIError(errorDescription: "FBSimulatorHIDEvent does not support touch move events.")
This is with AXe 1.7.1, Xcode 26.5, and an iOS 26.5 simulator. axe swipe / XcodeBuildMCP swipe works, but axe drag fails before dispatch because FBSimulatorHIDEvent.touchMoveAtX:y: is not available at runtime.
Error: CLIError(errorDescription: "FBSimulatorHIDEvent does not support touch move events.")
Expected
axe drag should either perform a drag on supported simulator stacks or gracefully fall back / explain which Xcode or SimulatorKit versions support the required touch-move selector.
Environment
From xcodebuildmcp-doctor and local commands:
AXe: 1.7.1
XcodeBuildMCP: 2.6.2
Xcode: 26.5 (17F42)
macOS: 26.5 / Darwin 25.5.0
Architecture: arm64, Apple M1 Pro
Node: v26.3.0
Installed simulator runtimes:
iOS 26.4.1 (23E254a)
iOS 26.5 (23F77)
Notes
I traced the failure to Sources/AXe/Utilities/HIDInteractor.swift, where touchMoveEvent(x:y:) looks up the private class method:
NSSelectorFromString("touchMoveAtX:y:")
On this host, class_getClassMethod(FBSimulatorHIDEvent.self, selector) returns nil, causing the error above.
A possible workaround might be a fallback path using FBSimulatorHIDEvent.swipe(...) where appropriate, although that would not be equivalent to a true held touch-move drag for sliders or custom controls.
#9 - Add tap by accessibility id/label [merged] #20 - fix(touch): make long press gestures reliable [merged] #39 - fix(describe-ui): Add point option support [merged] #44 - fix(commands): orientation-aware coords for both rotated devices and letterboxed landscape-only apps (#5) [merged] #49 - feat(drag): Add precision drag and slider commands [merged]
📝 Issue Planner
Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.
Create Plan
🧪 Issue enrichment is currently in open beta.
You can configure auto-planning by selecting labels in the issue_enrichment configuration.
To disable automatic issue enrichment, add the following to your .coderabbit.yaml:
issue_enrichment:
auto_enrich:
enabled: false
💬 Have feedback or questions? Drop into our discord!
Reproducible with axe slider as well, and on an older Xcode than the report: Xcode 16.2 (16C5032a), macOS 14.6.1, AXe 1.7.1 via Homebrew, iPhone 16 Pro simulator on iOS 18.3. So this does not appear to be Xcode 26-specific.
Repro with an open-source app
The react-native-webrtc-kaleidoscope demo ships sliders that carry stable accessibility identifiers, which makes the failure easy to reproduce by id:
git clone https://github.com/simiancraft/react-native-webrtc-kaleidoscope
cd react-native-webrtc-kaleidoscope/demo
npm install
npm run ios # expo run:ios against a booted simulator
In the demo select Shaders > Sky > Dawn; the SKY panel exposes per-channel color sliders. Then:
$ axe slider --id kld.clouds-dawn.sky.uSkyLowColor.r --value 10 --udid <udid>
Error: CLIError(errorDescription: "FBSimulatorHIDEvent does not support touch move events.")
Any slider reproduces it; this app just provides addressable ones.
Where the error originates
Sources/AXe/Utilities/HIDInteractor.swift: touchMoveEvent resolves touchMoveAtX:y: on FBSimulatorHIDEvent dynamically via NSSelectorFromString and throws this exact CLIError when the selector is missing. Both slider and drag route through performCompositeDrag (touch down, N touch moves, touch up), so both fail whenever the linked FBSimulatorControl build does not expose that method.
A fix path that works today
On the same machine the composite swipe event is fine: axe swipe along the slider's track (from the current thumb position, derived from the element's frame and AXValue, to the target fraction) moves the thumb reliably, and re-reading AXValue confirms it. Against the same slider:
So one option is for performCompositeDrag to fall back to FBSimulatorHIDEvent.swipe(...) when touchMoveAtX:y: is unavailable; Slider.swift already polls AXValue after the drag, so the verification half of that path is in place.
Activity
coderabbitai commentedon Jun 12, 2026
🔗 Related PRs
#9 - Add tap by accessibility id/label [merged]
#20 - fix(touch): make long press gestures reliable [merged]
#39 - fix(describe-ui): Add point option support [merged]
#44 - fix(commands): orientation-aware coords for both rotated devices and letterboxed landscape-only apps (
#5) [merged]#49 - feat(drag): Add precision drag and slider commands [merged]
📝 Issue Planner
Check the box below or use the
@coderabbitai plancommand to generate an implementation plan and prompts that you can use with your favorite coding assistant.🧪 Issue enrichment is currently in open beta.
You can configure auto-planning by selecting labels in the issue_enrichment configuration.
To disable automatic issue enrichment, add the following to your
.coderabbit.yaml:💬 Have feedback or questions? Drop into our discord!
the-simian commentedon Jul 1, 2026
Reproducible with
axe slideras well, and on an older Xcode than the report: Xcode 16.2 (16C5032a), macOS 14.6.1, AXe 1.7.1 via Homebrew, iPhone 16 Pro simulator on iOS 18.3. So this does not appear to be Xcode 26-specific.Repro with an open-source app
The react-native-webrtc-kaleidoscope demo ships sliders that carry stable accessibility identifiers, which makes the failure easy to reproduce by id:
In the demo select Shaders > Sky > Dawn; the SKY panel exposes per-channel color sliders. Then:
Any slider reproduces it; this app just provides addressable ones.
Where the error originates
Sources/AXe/Utilities/HIDInteractor.swift:touchMoveEventresolvestouchMoveAtX:y:onFBSimulatorHIDEventdynamically viaNSSelectorFromStringand throws this exactCLIErrorwhen the selector is missing. Bothslideranddragroute throughperformCompositeDrag(touch down, N touch moves, touch up), so both fail whenever the linked FBSimulatorControl build does not expose that method.A fix path that works today
On the same machine the composite swipe event is fine:
axe swipealong the slider's track (from the current thumb position, derived from the element'sframeandAXValue, to the target fraction) moves the thumb reliably, and re-readingAXValueconfirms it. Against the same slider:So one option is for
performCompositeDragto fall back toFBSimulatorHIDEvent.swipe(...)whentouchMoveAtX:y:is unavailable;Slider.swiftalready pollsAXValueafter the drag, so the verification half of that path is in place.Happy to test a branch.