In Appium, what does the `id` locator strategy match on Android, and what on iOS?

## What `id` is at the wire level A find in Appium is an HTTP request: `POST /session/:sessionId/element`, carrying a body of `{"using": "id", "value": "..."}`. `id` is one of the strategy names both native drivers declare — it is on the UiAutomator2 driver's list for Android and on the XCUITest driver's list for iOS, iPadOS and tvOS. **Appium's core does not define what `id` means.** The driver that owns the session decides which attribute of the on-screen element the string is compared against, and the two mobile drivers picked attributes that have nothing to do with each other. That shared strategy name is exactly what makes the trap convincing. The request is well formed on both platforms, the server answers on both, and one page object compiles and runs everywhere. Nothing in the protocol tells you that the two runs consulted different data. ## Android: `id` reads the `resource-id` attribute On Android the UiAutomator2 driver matches the element's **`resource-id`** attribute — the same value the page source and the inspector display for that node. - The full form is package-qualified, for example `com.example.app:id/login_button`. - Given a bare `login_button`, the driver prepends the package under test before matching, which is why most suites get away with writing the short name. - The UiAutomator2 setting `disableIdLocatorAutocompletion` turns that prefixing off, which is what you need when the identifier was authored without a package. - The value is fixed when the app is built, so it is **not localised** — the same string in every language and every locale. - It carries **no uniqueness guarantee**. A list can render the same `resource-id` on every row, so a single-element find returns the first match and tells you nothing about the other twenty. - It is not part of the accessibility tree. A control can be perfectly addressable by `id` and still be unlabelled for a screen reader. ## Apple platforms: `id` is an alias for `name` The XCUITest driver resolves `id` against its **`name`** attribute, which it fills from the element's **`accessibilityIdentifier`**. Two consequences follow, and both surprise people arriving from Android: 1. `id`, `name` and `accessibility id` are **three strategy names for one attribute** here. Swapping between them changes nothing about which element comes back. 2. The value lives in the **accessibility layer**, so it exists only where app code put it there. A button with no identifier has no `id` to match, however obvious its caption looks on screen. There is one further wrinkle worth carrying: when the identifier is empty, XCUITest falls back to the element's accessibility label when it computes `name`, so an `id` find on Apple platforms can quietly match a **visible, translated** string and pass in English while failing in German. Nothing equivalent happens on Android, where `resource-id` is never a caption. ## The two side by side | | Android (UiAutomator2) | Apple platforms (XCUITest) | |---|---|---| | attribute matched | `resource-id` | `name` | | source of the value | the app's build resources | `accessibilityIdentifier` | | written form | `com.example.app:id/login_button` | a bare string, no prefix | | automatic prefixing | yes, switched off by `disableIdLocatorAutocompletion` | none | | relation to `accessibility id` | a different matcher on a different attribute | the same matcher — both alias `name` | | can match a translated caption | no | yes, when the identifier is unset | ## Writing the locator honestly Because the meaning is per-platform, the locator has to be per-platform too, and the discipline is small: 1. **Name the platform wherever the locator is defined.** A constant called `LOGIN_ID` used by both runs is a claim that the two attributes agree; make that claim explicit or split the constant. 2. **Read the value out of the live source, not out of the app's code.** `GET /session/:sessionId/source` shows exactly what the driver will compare against on that device. 3. **Expect the Android value to be long and the Apple value to be short.** If your iOS locator contains a colon and a slash, someone pasted an Android identifier into it. 4. **Do not assume one find equals one element** on either platform; check how many matches a multi-element find returns before trusting the first. ## The failure modes to expect - An `id` that resolves on Android and returns nothing on iOS, because app code set the resource identifier and never set `accessibilityIdentifier`. - An `id` that resolves on iOS and returns nothing on Android, because the identifier exists only in the accessibility layer. - An `id` find on iOS that passes in one language and fails in another, because it landed on the label fallback rather than a real identifier. - An `id` find on Android that returns the wrong row, because every row in the list shares the identifier and the driver handed back the first. The leaf-level thesis is short: `id` is portable as a **keyword** and not as a **meaning**. Treat it as two strategies that happen to share a spelling, and the surprises stop.