skip to content

Why does Appium's `-android uiautomator` strategy have no Apple counterpart, and what warning ships with it?

level: seniorimportance: nice to knowfreq 33%

answer

  1. a front end to Google's framework
  2. Android ships UiAutomator, Apple does not
  3. the vendor owns the API, not Appium
  4. driver docs flag its retirement

basics

~20 s

It is a pass-through to Google's UiAutomator framework, which exists only on Android; Apple platforms have no equivalent, and Appium's XCUITest driver ships its own dialects. The driver's own documentation warns that Google intends to retire the underlying UiSelector API.

solid answer

~40 s

`-android uiautomator` is not a query language Appium designed. It is a text front end to `UiSelector`, a class in Google's **UiAutomator** framework, which is part of Android — so there is nothing to port to Apple platforms, and Appium's XCUITest driver declares its own iOS-only strategies instead. The borrowing cuts both ways. Appium's UiAutomator2 driver documents that Google plans to retire the `UiSelector` API, so this dialect rests on a framework Appium neither owns nor can keep alive. That is a **durability** caveat rather than a syntax one: nothing about it stops working today, and the strategy is still declared and still evaluated on the device. It is simply the one strategy in the Android set whose lifetime is decided by a third party.

go deeper

for a junior

Remember that this strategy exists only on Android because the class it wraps ships with Android, and that Apple platforms are served by a different driver with different dialects entirely.

for a middle

Explain that Appium is carrying somebody else's matcher API here, and that the driver's documentation warns the underlying API is expected to be retired by its vendor.

for a senior

Separate the warning from a removal: the strategy still works and is still declared. Be able to say what would actually break and how you would locate every affected locator.

for a principal

Own the dependency question: one part of the Android locator surface has its lifetime decided outside the project, and that risk is concentrated rather than spread. Decide how visible you want it to be.

## It is Android's class, not Appium's Most Appium locator strategies are Appium's own abstractions over what a platform exposes. `-android uiautomator` is different in kind: the selector value is a chain of calls on `UiSelector`, and `UiSelector` is a class in **UiAutomator**, the UI-testing framework that ships with Android. Appium's UiAutomator2 driver carries the text to its on-device server, which reconstructs those calls and lets the framework do the matching. That is the whole explanation for the strategy's shape, its power and its limits: - Its **vocabulary** is whatever `UiSelector` offers — no more, no less. - Its **semantics** are the framework's, so questions about what a matcher means are questions about Android, not about Appium. - Its **availability** follows the framework, so it exists exactly where UiAutomator exists. - Its **lifetime** is not Appium's to guarantee, because the API belongs to somebody else. ## Why Apple platforms have no twin Apple platforms do not ship UiAutomator, and there is no class to expose. Appium's XCUITest driver therefore declares its own iOS-only selector dialects for the same job — expressing a richer match than a plain id or class name can. Those dialects are a separate subject with a separate grammar; the point here is only that they exist **because** the Android dialect could not be carried across. This is worth saying precisely in an interview, because "Appium is cross-platform" invites the wrong inference. Appium's *protocol* and its *session model* are shared. Its **locator dialects are not**: the ones that go beyond the portable strategies are, by construction, front ends to a platform's own matching framework, and each platform brought a different one. | aspect | Android, via the UiAutomator2 driver | Apple platforms, via the XCUITest driver | |---|---|---| | underlying framework | Google's UiAutomator | Apple's own test framework | | expression-style strategies | `-android uiautomator` | the driver's iOS-only dialects | | who evaluates the expression | the driver's on-device server | the agent running on the device | | portable to the other platform | no | no | ## The retirement warning The second half of the question is the part candidates rarely have. Appium's UiAutomator2 driver documentation attaches a caution to this strategy: the `UiSelector` API it fronts is on its vendor's way out, and Google is expected to retire it. Appium can keep the strategy declared for as long as the framework answers, but it cannot preserve an API it does not own. What that warning does and does not mean: - It **does** mean this dialect is the least durable part of the Android locator set, and the only one whose future is decided outside the project. - It **does** mean an expression-heavy suite carries a concentrated migration risk: every locator written in this dialect is affected together. - It **does not** mean the strategy has been removed, or that it fails today. It is still declared by the driver and still evaluated on the device. - It **does not** affect the other strategies the driver declares, because none of them takes a `UiSelector` expression. ## What it changes about how the mechanism is used The practical read is narrow and mechanical. Where a plain matcher can express the match, an expression buys nothing but a dependency. Where a plain matcher genuinely cannot — a criterion the simple strategies do not carry, a relationship between two nodes, a search that has to traverse a list — the expression is the mechanism that exists, and the warning is a reason to keep those uses identifiable rather than a reason to pretend they are avoidable. Keeping them identifiable matters more than it sounds. Because every one of these locators is a string, any future migration cannot be driven by the compiler; it has to be driven by finding the strings. A suite that can answer "which of our locators are expressions?" in one search is in a very different position from one that cannot. ## Saying it well A compact answer to this question has three beats: 1. The strategy is a **text front end to a class that ships with Android**, so it exists where that framework exists and nowhere else. 2. Apple platforms have **no equivalent framework**, which is why the XCUITest driver declares its own dialects rather than accepting this one. 3. The driver's documentation **flags the underlying API's retirement**, which is a durability caveat about a dependency Appium does not own — not a claim that anything is broken now. That framing also answers the follow-up that usually comes next: no, being on Android is not enough on its own, because a session driven by Appium's Espresso driver has a different on-device server and a different strategy list.

  • If Google retires `UiSelector`, what breaks first in an Appium Android suite?
    The expressions, not the sessions. `-android uiautomator` is the only strategy whose value is a `UiSelector` chain; the other strategies the UiAutomator2 driver declares take plain values and carry no expression. The blast radius is exactly the set of expression-shaped locators, which is also why they are worth being able to enumerate.
  • Which Appium driver would you not expect to accept a UiSelector expression, even on Android?
    Appium's Espresso driver. It answers finds with its own on-device server and a different strategy list, so `-android uiautomator` is not available there. Running on Android is not sufficient — the driver chosen for the session decides which locator dialects exist in it.

saying these in an interview costs you the question

  • Thinks Appium invented and maintains the UiSelector API
  • Expects an Apple equivalent of the uiautomator strategy to exist
  • Says the strategy has already been removed from Appium
  • Assumes a retirement warning means it fails today
  • Treats the dialect as portable because Appium is cross-platform