An Appium xpath loop over 40 tram fare-inspection rows crawls on iOS but not on Android - why?

## The loop is not forty reads, it is forty documents A tram fare-inspection case that walks forty scanned-ticket rows and reads each one with its own `xpath` find looks, from the test's side, like forty cheap reads. From the driver's side it is forty full serialisations of the accessibility hierarchy. Neither platform evaluates XPath against a live tree. On Android the UiAutomator2 driver's on-device server builds an XML document from the accessibility node tree; on iOS `WebDriverAgent` builds one from an XCTest element snapshot. Each build serves exactly one find call, and nothing is cached between them. That is the first multiplier, and it applies to both lanes equally. ## The second multiplier is the platform The two documents do not cost the same to produce. - On **Android**, the UiAutomator2 server reads an accessibility node tree the platform already maintains, from a process that can see it directly. - On **iOS**, `WebDriverAgent` has to obtain an XCTest element snapshot of the application under test, which is heavier and crosses into the app. | | Android, UiAutomator2 driver | iOS, XCUITest driver | |---|---|---| | Document built from | the accessibility node tree | an XCTest element snapshot | | Built by | the on-device UiAutomator2 server | `WebDriverAgent` | | Forty single finds cost | forty node-tree serialisations | forty snapshots plus forty XML builds | | Cheaper same-lane strategy | `accessibility id`, `-android uiautomator` | `-ios predicate string`, `-ios class chain` | The XCUITest driver's own documentation puts a figure on it: an `xpath` lookup there can be **up to ten times slower** than the equivalent `-ios class chain` or `-ios predicate string` lookup. Multiply a per-row loop by that unit cost and the iOS lane does not degrade gracefully - it dominates the run, while Android merely wastes time. ## Reading the symptom correctly Before rewriting anything, confirm the cost is where you think it is: 1. **Time the finds, not the test.** The Appium server log records each command, so the duration of the find calls themselves is visible on both platforms without instrumenting the suite. 2. **Compare strategies on the same screen.** Re-run the same case with a per-platform strategy - `accessibility id` on Android, `-ios predicate string` on iOS - and see whether the gap follows the strategy or the application. 3. **Check whether the cost tracks tree size.** If a fare list with more rows costs proportionally more per find, that is serialisation rather than application work. ## The fixes, in order of how much they buy - **Stop paying per row.** One `findElements` call with the same expression returns every matching row from a single serialisation, and you then read attributes off the returned elements. This is the single largest win, and it applies to both lanes. - **Move the hot finds off `xpath` entirely.** On Android the UiAutomator2 driver's `id`, `accessibility id` and `-android uiautomator` are matched by the on-device server; on iOS the XCUITest driver's `-ios predicate string` and `-ios class chain` are what its docs recommend for exactly this reason. - **Scope the find, carefully.** An element-scoped `xpath` find still triggers a serialisation, and whether it is matched against the element's subtree or the whole page source depends on `limitXPathContextScope`, which both drivers expose. Scoping helps only when it genuinely shrinks the work. - **Reduce how much tree there is at all.** Both drivers expose settings that bound what goes into the hierarchy; that is a separate lever from the locator strategy, and it applies to every find rather than just the loop. ## What does not help - Shortening the expression. Evaluation is the cheap half, the build is the expensive half, and the build happens either way. - Replacing a relative path with a long absolute one. Same document, same build, same cost. - Wrapping each find in a retry. That multiplies the serialisations instead of removing them. - Assuming both lanes will respond to the same fix by the same amount. They will not, because the unit costs differ. ## Why this bites on mobile and not in a browser Worth being explicit, because the instinct usually comes from browser work. A browser answers an XPath query out of a document it already holds, so the cost is roughly the cost of the query. A mobile driver has to build the document first, so the cost is roughly the cost of the screen. That inverts the tuning advice: in a browser you tune the expression, and on Android and iOS you tune **how often** you ask and **how much tree** each ask has to cover. A forty-row loop is the worst possible shape under that model, and it is the shape a suite falls into naturally when a page object exposes one row-reading helper and a case calls it once per row.