Element Addressing

In Appium's iOS class chain strategy, a single slash requires the next element type to be a direct child of the previous match, while a double-star slash lets it sit at any depth below.

On Android the id strategy matches an element's resource-id, the package-qualified identifier fixed in the build. On iOS it is an alias for the name attribute, which XCUITest fills from the accessibility identifier. Same keyword, two unrelated attributes.

A React Native testID sets the iOS accessibilityIdentifier, which the XCUITest driver exposes behind the name attribute, and on Android it surfaces as the view's resource-id in the page source. Android's content-desc is filled by accessibilityLabel instead.

It sends a UiSelector expression as a plain string of chained Java-style calls. Appium's Android UiAutomator2 driver passes it to its on-device server, which parses the text and lets Google's UiAutomator framework match the live view hierarchy.

A JSON object describing a matcher to build on the device: name for the matcher method, args for its arguments, and class for the class holding that static method. The on-device Espresso server builds it and passes it to onView.

A backtick segment filters the element the step names by that element's own attributes. A dollar-sign segment matches the same step by one of its descendants instead, so Appium's iOS class chain can address a container by what is inside it.

Android's UiAutomator2 driver exposes the switch position as its own attribute, checked, reading back as true or false. iOS's XCUITest driver folds the position into the general value attribute, where an on switch reads back as 1.

On Android the class name strategy matches a fully qualified widget class such as android.widget.Button. On iOS it matches an XCUIElementType value such as XCUIElementTypeButton. Both are exact string comparisons over two vocabularies that share nothing.

Appium's XCUITest driver, which automates Apple platforms, accepts -ios predicate string: an NSPredicate that filters elements by attribute — type, name, label, value — using comparison and logical operators. It matches attributes only, never hierarchy, and Android's drivers do not accept it.

Both drivers honour snapshotMaxDepth. Android's UiAutomator2 adds allowInvisibleElements, ignoreUnimportantViews and enableMultiWindows; Apple's XCUITest adds snapshotMaxChildren, useJSONSource, includeHittableInPageSource and pageSourceExcludedAttributes. Same job, almost entirely different names.

Android's UiAutomator2 driver serialises the accessibility node hierarchy the platform publishes. Apple's XCUITest driver serialises an XCUIElement snapshot WebDriverAgent takes through XCTest. Neither is the app's own view hierarchy, so whatever those layers withhold is unaddressable.

By default Appium's UiAutomator2 driver completes a bare id locator with the app package before matching Android's resource-id. Setting disableIdLocatorAutocompletion to true makes the driver match the string exactly as written, which is what a generated test id needs.

Chained UiSelector calls narrow the match: every criterion must hold on the same node. Two calls are exceptions — childSelector moves the rest of the expression to a descendant, and fromParent moves it to a sibling subtree.

Because -android datamatcher does not search views. The on-device Espresso server passes the built matcher to onData, which searches the objects behind an AdapterView and then materialises the matching row. A hierarchy walk can only see rows already inflated.

Neither platform evaluates XPath natively, so each xpath find first serialises the accessibility hierarchy into an XML document - built by the UiAutomator2 server on Android and by WebDriverAgent on iOS - and matches the expression against that copy.

Work down the expression: full XCUIElementType name for type, quoted string literals, the attribute you actually meant, case and diacritics, and MATCHES matching the whole string. Then confirm the control is really in the session's source with those attributes.

A predicate that compares label is comparing translated, accented copy with a case- and diacritic-sensitive operator. In Appium's iOS strategy, append [cd] to CONTAINS or BEGINSWITH, or match a stable name attribute instead of visible text.

A minus-one index selects the last element that step matched. Appium's iOS class chain numbers a step's matches from 1, not 0, and a negative index counts backwards from the end of that list.

Both platforms use the same request: GET /session/:sessionId/element/:elementId/attribute/:name, with an element identifier from an earlier find and exactly one attribute name in the final segment. Only which names are valid differs by platform.

Both platforms answer the W3C endpoint GET /session/:sessionId/source, which returns the current screen as one XML tree. Apple's XCUITest driver additionally exposes a mobile: source execute method; the Android drivers ship no equivalent.

All three are Android strategies of Appium's Espresso driver. The datamatcher one builds a matcher for onData over an AdapterView's data; the viewmatcher one builds a matcher for onView over rendered views; the viewtag one matches a view's tag.

Because on Android the strategy compares only content-desc, a field separate from the text a widget renders. A button can display a caption and carry no description, and there is no fallback, so the find fails.

Because the XCUITest driver answers that lookup with the element's name attribute, and name falls back to the element's visible localised label when the accessibilityIdentifier is empty. The match then depends on product copy, not on a stable token.

Both drivers declare the strategy and both compare a plain string, so an identical find request is legal on either platform. The travelling is done by the application, which must carry the same string in two unrelated app-side fields.

Android's UiAutomator2 driver answers the whole question with one attribute, displayed. iOS's XCUITest driver splits it in two: visible says the element is drawn, hittable says a touch aimed at it would actually land on it.

Nothing changes on iOS. XCUITest aliases id, name and accessibility id onto the same name attribute, so all three return the same element. On Android the swap changes the matched attribute entirely, and the results diverge.

A Compose test tag lives in Compose's own semantics description, and Appium's UiAutomator2 driver reads Android's accessibility node tree instead. The UiAutomator2 setting mapTestTagToResourceId is what reports that tag in the resource-id slot so an id locator can reach it.

The UiSelector passed to UiScrollable addresses the scrollable container, usually one with scrollable set to true. The UiSelector passed to scrollIntoView addresses the element you actually want back. Swapping the two is the common mistake.

Treat it as a one-sided address, not a broken locator. Confirm the Android element's content-desc holds the token, then read the Apple element's name attribute: the usual cause is that the Apple build never set that identifier.