In Appium, when is it worth leaving the W3C command set for a driver's mobile: method?

## Two surfaces with opposite properties An Appium session gives a test two command surfaces, and choosing between them is a design decision rather than a matter of taste. The **inherited surface** is W3C WebDriver: find an element, click it, send keys, read an attribute, take a screenshot, post an action chain, set a timeout. Its property is portability. The same call drives a curling-club ladder session through the UiAutomator2 driver on Android, through the Espresso driver on Android, and through the XCUITest driver on Apple platforms, and it survives a driver swap without a rewrite. The **extension surface** is the driver's own: capabilities under the `appium:` vendor prefix, and execute methods invoked by posting a name such as `mobile: …` to `POST /session/:sessionId/execute/sync`. Its property is capability. It can install the ladder build, background it, clear its stored data, fling a long standings list in one call, or drive a device facility a browser protocol never imagined. ## What the inherited surface really guarantees Portability of the **call shape**, not of the behaviour. A driver may answer a standard route itself or proxy it to an on-device agent, and that agent's rules then apply. The Espresso driver on Android proxies its find and action routes to the server running on the device, so its node-side declarations are not the whole story and its matching behaviour is that server's. Expect the same request to run everywhere; do not expect identical timing, identical error text, or an identical element set. ## What an execute method costs - **The name is per driver.** Flinging the standings is `mobile: swipeGesture` on the UiAutomator2 driver for Android and `mobile: swipe` on the XCUITest driver for Apple platforms. There is no shared spelling to fall back on. - **Availability can be narrower than the platform.** `mobile: networkSpeed` on the Android drivers works on emulators only, and `mobile: clearApp` is real on iOS but only on a simulator, throwing on a real device. A green simulator run proves nothing about the device fleet. - **Parameters are per command.** The single object in `args` is defined by that driver's execute-method map, so the other platform's equivalent usually takes different members. - **Nothing is checked at session start.** A name the current driver does not answer fails at the step, deep into a run, not at session creation. - **The surface moves with the driver.** Execute methods are a per-driver contract, so a driver upgrade is exactly where one can change under you, while the standard routes move at the pace of the specification. - **Documentation is not the contract.** A name that appears only in prose may not exist: the XCUITest driver's reference prints `mobile: availableConditionInducer`, which is nowhere in its source — the real command is `mobile: listConditionInducers`. ## A decision rule that holds up 1. **Default to inherited.** Anything the suite does hundreds of times — locate, tap, type, read an attribute — stays on the standard commands, so a driver change is a configuration change and not a rewrite. 2. **Leave it when the intent cannot be expressed at all.** Installing a build, backgrounding the app, clearing its stored data and reading device state have no W3C equivalent. There is no judgment call here; use the driver's method. 3. **Leave it when the standard route is measurably worse.** A hand-scripted action chain to fling a long ladder list is longer, slower and flakier than one driver gesture call. Prefer the driver's, and be able to say what "measurably" meant when you measured it. 4. **Do not leave it out of curiosity.** Every execute method the suite depends on is another per-driver contract to re-verify at the next driver upgrade. ## Containing the divergence The cost of the extension surface is not that you use it; it is where the per-driver name ends up. Keep the platform choice in one place the tests call — a single function that knows whether this ladder run is talking to the Android drivers or to the XCUITest driver, and that sends the right name with the right parameter map — so a rename, a gating surprise or a new driver is one edit. A `mobile:` string typed inline across fifty cases is fifty edits and fifty chances to leave one on the wrong platform. | | Inherited W3C commands | Driver execute methods | |---|---|---| | Name | one spelling everywhere | per driver | | Availability | wherever the driver runs | can be simulator- or emulator-only | | Changes with | the specification | the driver release | | Right for | the steps you repeat constantly | intents the standard set cannot express | ## What a strong answer sounds like Not "always prefer the standard commands" and not "use `mobile:` for everything", but a stated line with a reason behind it: the inherited surface is where the suite's volume lives, because portability compounds there; the extension surface is where the suite's power lives, because mobile intents mostly have no W3C spelling; and the boundary between them is one call site, so neither half's churn reaches the tests. A candidate who can also name what they gave up — a slower path here, an extra per-driver dependency there — is describing a decision rather than a preference.