In Appium, which driver ships mobile: swipeGesture and which ships mobile: swipe?

## Where a gesture command comes from Appium speaks the W3C WebDriver protocol, and that protocol was written for browsers. It has a click, a send-keys and a low-level pointer API, but no vocabulary at all for a fling, a pinch or a pressure-sensitive press. Everything a driver offers beyond the standard set is exposed as an **execute method**: a script name of the form `mobile: <name>` plus a single parameter map, posted to `POST /session/:sessionId/execute/sync`. Gesture shortcuts are the largest family of these on the mobile drivers, because each platform's own UI-testing engine already knows how to inject those inputs natively and the driver only has to expose them. The structural consequence is the whole of this topic: **an execute method belongs to a driver, not to Appium**. There is no catalogue that every driver must implement, and no normalising layer in the server. Each driver declares its own execute-method map, and a name outside that map is not a command for that session. ## The two vocabularies | Gesture | Android — UiAutomator2 driver | Apple platforms — XCUITest driver | |---|---|---| | Swipe | `mobile: swipeGesture` | `mobile: swipe` | | Tap | `mobile: clickGesture` | `mobile: tap` | | Long press | `mobile: longClickGesture` | `mobile: touchAndHold` | | Double tap | `mobile: doubleClickGesture` | `mobile: doubleTap` | | Drag | `mobile: dragGesture` | `mobile: dragFromToForDuration` | | Pinch | `mobile: pinchOpenGesture` / `mobile: pinchCloseGesture` | `mobile: pinch` | | Momentum throw | `mobile: flingGesture` | no command of that name | | Pressure press | no command of that name | `mobile: forcePress` | Not one row shares a spelling. There is a visible pattern — UiAutomator2 suffixes its gesture names with `Gesture` and XCUITest does not — but it is a pattern, not a rule you can apply blindly. XCUITest also ships `mobile: tapWithNumberOfTaps`, `mobile: twoFingerTap`, `mobile: rotateElement`, `mobile: selectPickerWheelValue` and `mobile: rotateDigitalCrown`, none of which has an Android twin under any name. ## The split follows the driver, not the operating system It is tempting to file this as "Android says one thing, iOS says another". That reading breaks on Appium's Espresso driver, which is an Android driver and yet names its swipe `mobile: swipe`, exactly as XCUITest does. Appium's Android drivers are not one driver: UiAutomator2 and Espresso are separate extensions chosen by `appium:automationName`, and the gesture map you get is the one the chosen driver declares. So the honest rule is: - The command name is a property of the **driver**, not of the platform. - Two sessions on the same Android phone can want different gesture names. - `platformName` is therefore the wrong key to branch a shared helper on. - The only reliable source is what the driver in play declares. ## What the wrong name actually does Suppose a mountain-hut reservation suite scrolls its list of huts by posting `mobile: swipeGesture`. On a UiAutomator2 session the list moves. Point the same helper at an XCUITest session and the step does not degrade into a shorter or slower swipe — the driver has no execute method registered under that name, so the `execute/sync` call comes back as a failure and the step dies immediately. That is a mercy, not a nuisance: a silent no-op would let an assertion pass over a screen that never scrolled. The symmetric mistake is worse, because it reads as correct. Writing "UiAutomator2's `mobile: swipe`" pairs two real identifiers and is still false; no spell-check and no identifier search can catch it, and a reader who copies it spends an afternoon hunting a command their driver never had. Attribute every gesture to its driver by name, every time. ## Reading a gesture call in review When a `mobile:` gesture turns up in a diff, four questions settle whether it is right: 1. Which driver did this session start with, and does that driver declare this name? 2. If the helper is shared, where does it branch, and does the branch key survive an Espresso session? 3. Does this gesture have a counterpart on the other driver at all, or is it platform-only code? 4. Are the arguments the ones this driver's command takes, or the other driver's arguments in disguise? ## Why it is worth knowing at the first tier This is the cheapest piece of Appium knowledge on the interaction surface and it saves the most time. Someone who knows only that the names diverge will look the right one up. Someone who believes Appium normalises gestures will write a shared helper, watch it fail on one platform, and reach for a retry or a sleep to fix something that is not intermittent at all. The failure is deterministic, and its cause is spelled out in the command name itself.