No way to observe the screen mid-press: gesture-custom / long-press block until release and screenshot queues behind them

[finloop]

Summary

There is no way to observe the screen while a touch is held. gesture-custom (Down … Up with delayMs) and the flow runner's long-press step both block until the finger lifts, and a screenshot issued alongside is serialised behind the gesture. So any UI state that exists only during a press (a withSpring scale on onPressIn, a pressed style, a hold-to-reveal control) cannot be captured or asserted on.

Repro (argent 0.24.0, iOS simulator, iPhone 17 Pro / iOS 26.5)

React Native 0.72 app with Reanimated 3.5.4; a TouchableOpacity that sets scale.value = withSpring(1.5) on onPressIn and back to 1 on onPressOut.

1. Call gesture-custom with [{type:"Down",x,y},{type:"Up",x,y,delayMs:3000}].
2. In the same MCP batch, call screenshot for the same udid.

Observed: the gesture call returns after ~3 s; the screenshot's saved file is timestamped ~30 ms after the gesture result, and shows the box at scale 1 (already released). Same outcome with delayMs: 1500, and with a long-press flow step. A parallel xcrun simctl io screenshot from a shell also landed after release both times I tried.

Expected: some way to capture or query the screen while the touch is still down.

Why it matters

Press-and-hold states are a common thing to verify in a UI test (pressed styles, spring scale on press, long-press menus before release, drag previews). Today the only option is screen-recording-start → gesture → screen-recording-stop and scrubbing the mp4, which is heavy and not assertable with await-ui-element.

Possible approaches

• A holdMs-style option on gesture-custom / gesture-tap that returns after the Down (plus optional hold) and leaves the touch down, with a separate touch-release (or an Up-only event) to lift it. describe / screenshot / await-ui-element could then run in between.
• Or an option on gesture tools to capture a screenshot at a given offset into the gesture (captureAtMs) and return it alongside the normal post-gesture screenshot.
• Or let screenshot run concurrently with an in-flight gesture instead of queueing behind it.

The first option composes best with run-sequence and flows (long-press could become press + await + release).