Real-Time Drag on a Real Device (Not Just Start and End Points)

There are two very different things people call "a swipe."

One is a synthesized gesture: press at point A, release at point B, and let the OS interpolate whatever happened in between. The other is a continuous stream of pointer events — every intermediate position, at the speed the finger actually moved.

Most apps behave identically under both. The interesting ones don't.

Why the difference shows up

A synthesized swipe hands the app an idealised motion: a straight line, uniform speed, and crucially, most of it delivered after the interaction is over. Anything that reacts while the finger is still down never gets exercised.

The features that care:

• Drag-and-drop reordering. The list has to reflow under the item as it moves. With start-and-end events the item teleports and the reflow logic is never run.
• Sliders and steppers. The value should track the finger continuously. A two-point gesture tests the final value and nothing else.
• Maps. Panning, momentum and tile loading all depend on velocity and direction over time.
• Canvas and signature capture. A signature drawn as a straight line from A to B is not a signature.
• Pull-to-refresh. The threshold, the rubber-banding, the spinner that appears partway — all mid-gesture states.
• Carousels with momentum. Whether a flick lands on the next card depends on how fast it was moving when released, not where it started.

If your remote testing tool only sends start and end, these are the bugs that reach production because they were never actually driven.

What real-time eventing means here

On RobotActions, dragging on the device view streams pointer events as you move — the way a desktop application receives mouse input. The app sees a continuous path with real timing, so mid-gesture behaviour runs exactly as it does under a real finger. Latency matters here too: a gesture stream that arrives late is a different gesture.

The same applies through the API. An AI agent driving the device over MCP can perform a real drag along a path rather than a two-point approximation, so agent-run tests exercise the same code paths a human would.

How to check your app

Pick the three screens most likely to depend on mid-gesture state — a reorderable list, a slider, and a map or carousel — and drive each one slowly:

1. Press and hold, then move gradually. Does the UI respond during the movement?
2. Stop halfway and hold still. Is the intermediate state correct, or does it look like nothing happened yet?
3. Reverse direction without releasing. Plenty of implementations only handle one axis of travel once a gesture is classified.
4. Release at speed. Does momentum carry the way it should?

Step 3 catches a surprising number of defects, because gesture recognisers often lock to a direction on first movement and never reconsider.

Try it on hardware

Real touch is imprecise, fast, and continuous. Testing it with two coordinates and an interpolation is testing a different input than your users have.

Drag on a real device and watch it respond live →