In Appium, what arguments do UiAutomator2's mobile: swipeGesture and XCUITest's mobile: swipe take?
answer
- one driver needs a distance argument
- percent has no Apple counterpart
- the element frame bounds the iOS swipe
- speed versus velocity, different names
basics
~20 sUiAutomator2's mobile: swipeGesture needs a target element or rectangle, a direction and a mandatory percent, plus an optional speed. XCUITest's mobile: swipe takes an optional element, a direction and an optional velocity, and has no percent at all.
solid answer
~40 sBoth are posted as a `mobile:` name plus one parameter map, but the maps are not parallel. UiAutomator2's `mobile: swipeGesture` wants a target — either an `elementId` or an absolute rectangle given as `left`, `top`, `width` and `height` — a `direction` of `up`, `down`, `left` or `right`, a **mandatory** `percent` between 0 and 1 saying how much of that area the finger crosses, and an optional `speed`. XCUITest's `mobile: swipe` wants an **optional** `elementId`, which when omitted applies the gesture to the whole application rather than one element, the same four `direction` values, and an optional `velocity`. The asymmetry that bites is `percent`: on Android distance is something you state, on Apple platforms it is decided by the target's frame and you can only tune speed.
code
java · 11 linesMap<String, Object> android = Map.of(
"elementId", hutListId,
"direction", "up",
"percent", 0.8);
driver.executeScript("mobile: swipeGesture", android);
Map<String, Object> apple = Map.of(
"elementId", hutListId,
"direction", "up",
"velocity", 2500);
driver.executeScript("mobile: swipe", apple);go deeper
Learn the two argument maps as a pair. Be ready to say that UiAutomator2's mobile: swipeGesture requires percent and that XCUITest's mobile: swipe has no distance argument at all.
Explain the asymmetry rather than listing keys. Distance is stated on Android and implied by the target's frame on Apple platforms, and speed and velocity tune motion, never reach.
Demonstrate that you check the argument contract per driver before writing shared code, and that you know a name shared across drivers, such as duration, can still carry different units and produce a silent behaviour difference.
Decide as a lead whether the suite exposes driver-shaped arguments honestly or a portable vocabulary, and make sure any portable vocabulary cannot express a parameter one driver has no way to honour.
## The same intent, two argument shapes Both drivers give you a one-call swipe, and both take it over `POST /session/:sessionId/execute/sync` as a `mobile:` name plus a single parameter map. What they ask for inside that map is where they part company, and the difference is not cosmetic: Appium's UiAutomator2 driver makes you say **how far**, and the XCUITest driver gives you no way to say it. ### UiAutomator2, on Android — `mobile: swipeGesture` - A target: either `elementId`, or an absolute rectangle given as `left`, `top`, `width` and `height`. - `direction`: one of `up`, `down`, `left` or `right`. - `percent`: a float between 0 and 1, **mandatory**, giving how much of the target area the gesture crosses. - `speed`: optional, how fast the finger travels. ### XCUITest, on Apple platforms — `mobile: swipe` - `elementId`: **optional**. Omit it and the swipe applies to the whole application rather than to one element. - `direction`: one of `up`, `down`, `left` or `right`. - `velocity`: optional, raising the speed of the swipe. ## The missing argument is the whole lesson `percent` has no XCUITest counterpart. On Android you compose a swipe out of an area and a fraction of that area; on Apple platforms you name a target and a direction, and the gesture spans the target's frame. So "swipe up 30% of the hut list" is directly expressible in a UiAutomator2 session and is simply not a thing you can ask XCUITest for. A shared helper that accepts a `percent` argument and drops it on the Apple side is not translating — it is doing something materially different on each platform under one name. `speed` and `velocity` are close cousins but they are not the same argument, and both are density-dependent: the same number does not produce the same visible motion on two devices with different screens. Treat them as tuning knobs of last resort, never as a way to express distance. ## The pattern repeats across the family | Intent | UiAutomator2 arguments | XCUITest arguments | |---|---|---| | Swipe | `direction` + `percent`, optional `speed` | `direction`, optional `velocity` | | Pinch | `percent` on `mobile: pinchOpenGesture` or `mobile: pinchCloseGesture` | `scale` + `velocity` on `mobile: pinch` | | Long press | `duration` on `mobile: longClickGesture`, in milliseconds | `duration` on `mobile: touchAndHold`, in seconds | | Momentum throw | `direction` + `speed` on `mobile: flingGesture` | no such command; raise `velocity` on `mobile: swipe` | Read the long-press row twice. Both commands take an argument called `duration`, and the two are documented in different units. A helper that passes 2000 meaning two seconds gets two seconds on one driver and something wildly different on the other. **Shared names are more dangerous than divergent ones**, because they look portable and never raise an error. Pinch is the same trap in a different shape. UiAutomator2 splits the gesture into two commands and lets `percent` say how far the fingers travel; XCUITest keeps one command and lets `scale` carry both magnitude and direction — above 1 spreads the fingers, below 1 brings them together. ## Working it through on the hut list A mountain-hut reservation app shows a scrollable list of huts and a date picker. To move the list by roughly a screenful: - On UiAutomator2 you post `mobile: swipeGesture` with the list's `elementId`, `direction` of `up` and a `percent` near 0.8, then assert that the hut you expected is on screen. - On XCUITest you post `mobile: swipe` with the same list's `elementId` and `direction` of `up`; you do not get to choose the fraction, and if one pass is not enough you post it again. - On either driver, scoping the gesture to the list element rather than to the whole screen keeps the date picker out of the motion. Neither call is wrong. They are different commands with different contracts that happen to serve the same intent, and the test code has to know which one it is talking to. ## What this question is really probing Anyone can recall two command names. The tell that you have actually driven both drivers is knowing that the argument maps are not parallel: that `percent` is required on one side and absent on the other, that `speed` and `velocity` are separate names for a related idea, and that a `duration` shared by spelling is not shared by meaning. Say the mandatory argument out loud, say what the other driver does instead of it, and the question is answered.
- How do you express a partial swipe on an Apple platform when mobile: swipe has no percent?You do not express it as a fraction. Scope the gesture to the smallest element that contains the motion you want, so that element's frame bounds the swipe, and post the command again if one pass is not enough. Raising velocity changes how fast the finger moves, not how far, so it is not a substitute for percent.
- Which XCUITest argument decides pinch direction, and what is UiAutomator2's equivalent?XCUITest's mobile: pinch takes a scale: above 1 spreads the fingers, below 1 brings them together, with velocity setting the speed. UiAutomator2 has no scale at all — it splits the gesture into mobile: pinchOpenGesture and mobile: pinchCloseGesture, and percent says how far the fingers travel.
saying these in an interview costs you the question
- Thinks percent is optional on UiAutomator2's mobile: swipeGesture.
- Passes a percent argument to XCUITest's mobile: swipe.
- Assumes both drivers swipe the same distance for the same call.
- Believes omitting elementId is invalid on XCUITest's mobile: swipe.
- Treats a duration shared by name as a duration shared by unit.
- Uses velocity or speed to try to change how far a swipe travels.