In Appium, which XPath dialect does Android's UiAutomator2 driver evaluate, and which does iOS?

## The same locator string, two different engines An Appium suite that shares one locator between an Android lane and an iOS lane is quietly relying on two different XPath implementations agreeing about it. They usually do, because most expressions live comfortably inside the intersection. When they do not, the failure is one-sided and confusing: the Android lane is green, the iOS lane finds nothing, and the locator string is character-for-character identical in both. The reason is that neither platform evaluates XPath natively. Each driver builds an XML document out of the accessibility hierarchy and runs an engine of its own choosing over that document - and the two drivers chose differently. ## Android: XPath 2, with a switch back The UiAutomator2 driver's on-device server evaluates **XPath 2** by default. Because that was a change from the older engine, the driver exposes a per-session setting, `enforceXPath1`, that forces the XPath 1 engine back. It exists as a compatibility escape hatch: an expression written and tuned against XPath 1 can evaluate differently under XPath 2, and pinning the session is cheaper than rewriting a suite's locators. Three things are worth holding about it: - It is a **driver setting**, set through the session's settings surface alongside the UiAutomator2 driver's other settings such as `limitXPathContextScope` and `snapshotMaxDepth`. It is not a capability and not a server flag. - It changes **which engine evaluates the expression**. It does not change how the document is built, so it makes no find cheaper. - It is Android-side only. There is no XCUITest equivalent to reach for. ## iOS: XPath 1.0, and nothing to set On iOS the XCUITest driver proxies the find to `WebDriverAgent`, which builds its XML from an XCTest element snapshot and evaluates **XPath 1.0**. The XCUITest driver's settings reference - the enumerable list of what that driver's settings surface accepts - carries no dialect switch at all. There is nothing to configure: iOS is XPath 1.0, and an expression that needs anything newer has no route through. That asymmetry is what makes this a divergence rather than a footnote. | | Android, UiAutomator2 driver | iOS, XCUITest driver | |---|---|---| | Default dialect | XPath 2 | XPath 1.0 | | Switch available | `enforceXPath1` | none | | Where the expression runs | the on-device UiAutomator2 server | `WebDriverAgent` | | Document built from | the accessibility node tree | an XCTest element snapshot | | Shared XPath setting | `limitXPathContextScope` | `limitXPathContextScope` | `limitXPathContextScope` is the only XPath-named setting the two drivers genuinely share, and it does the same job on both: it decides whether an element-scoped lookup is matched against that element's subtree or against the whole page source. ## What this costs a cross-platform suite 1. **A shared locator is only safe at the XPath 1 intersection.** If a tram fare-inspection suite runs the same expression against both lanes, write it so an XPath 1 engine can evaluate it, or accept two locators and maintain both. 2. **A green Android lane proves nothing about iOS.** The Android engine is the more permissive of the two, so it is the wrong lane in which to validate a shared expression. 3. **Pinning Android back with `enforceXPath1` is a legitimate way to align the lanes.** It makes the more permissive side behave like the stricter one, turning a one-sided iOS failure into a failure both lanes surface. 4. **A dialect mismatch and a missing element look identical from the test side.** Both are simply no match found, which is why this is worth checking before blaming the app. ## What the dialect does not buy you - It does not reduce cost. Both engines still need a serialised document per find, and that build is where the time goes on both platforms. - It does not change what is in the tree. What the document contains and how deep it reaches is configured separately, on both platforms. - It does not make `xpath` competitive with the per-platform strategies. On iOS the XCUITest driver's docs still warn that an `xpath` lookup can be up to ten times slower than an `-ios predicate string` or `-ios class chain` one, whichever dialect is in play. ## How to hold this in an interview State the shape, not a version number: Android's UiAutomator2 driver evaluates XPath 2 and can be pushed back with `enforceXPath1`, iOS through `WebDriverAgent` evaluates XPath 1.0 with no equivalent switch, and the working rule is to write shared expressions to the older dialect. If asked what to do about a locator that works in one lane only, say that you check the dialect before you touch the app, and that you would consider pinning the Android lane so that both sides agree about what is valid in the first place.