In Appium on iOS, what changes when you swap the `id` strategy for `accessibility id`?

## The asymmetry in one sentence On **Apple platforms** three locator strategies point at one attribute; on **Android** the equivalent strategies point at genuinely different attributes. Everything else in this question follows from that. ## What XCUITest actually declares The XCUITest driver's native strategy list is longer than the Android one, and it includes `id`, `name` and `accessibility id` as three separate entries. Reading that list, it is natural to assume three matchers. There are not three: - `id` resolves against the element's `name` attribute. - `name` resolves against the element's `name` attribute. - `accessibility id` resolves against the element's `name` attribute. So the three are **spelling variants of one lookup**. Sending `accessibility id` instead of `id` with the same value produces the same request outcome, the same element, and the same failure when the value is absent. There is no fallback from one strategy to another, because there is nothing to fall back to — they were already the same comparison. Where does `name` come from? XCUITest computes it from the element's `accessibilityIdentifier`, the field app code sets explicitly for automation. When that field is empty, the driver falls back to the element's accessibility label, which is the user-facing, **localised** string. That fallback is the reason an iOS `id` lookup can pass in one language and fail in another, and it applies identically to all three strategy names because they are one matcher. ## What UiAutomator2 declares The Android side declares `id` and `accessibility id` too, and there they are **different matchers over different attributes**: - `id` compares against `resource-id`, the package-qualified identifier fixed in the app's build, for example `com.example.app:id/login_button`. - `accessibility id` compares against a separate accessibility attribute, populated by different app-side code and by no means guaranteed to hold the same string. So on Android the swap is a genuine change of target. A value that resolves under one strategy commonly returns nothing under the other, and that is not a bug — the two attributes are simply not the same field. ## Side by side | strategy | Android (UiAutomator2) | Apple platforms (XCUITest) | |---|---|---| | `id` | matches `resource-id` | alias for `name` | | `name` | not declared | matches `name` | | `accessibility id` | matches a separate accessibility attribute | alias for `name` | | effect of swapping `id` for `accessibility id` | different attribute, usually different result | no effect at all | | number of distinct matchers involved | two | one | ## Why this matters when you read someone else's suite 1. **An iOS-only suite gives you no signal.** If the team standardised on `accessibility id` while shipping iOS first, the choice was free there; it becomes a real requirement the moment Android is added, because a second app-side field now has to be populated. 2. **A green iOS run does not validate the Android locator.** The strategies collapse on one platform and not the other, so identical test code exercises different app-side contracts. 3. **"We use `name` everywhere" is an Apple-only sentence.** `name` is not on UiAutomator2's declared strategy list, so that convention cannot be carried across as written. 4. **The label fallback is a shared hazard of the collapsed matcher.** Because all three iOS names route through `name`, none of them is safe from silently matching a translated caption when app code left the identifier unset. ## How to check rather than assume - Fetch the live tree with `GET /session/:sessionId/source` on each platform and read what the element actually carries; the attribute names in the source are the ground truth for that device. - Try the same value under both strategies on Android. If one returns an element and the other does not, you have just proved the two attributes hold different content in that build. - When an iOS lookup succeeds, check whether the value you matched is also a visible caption. If it is, you may be riding the label fallback rather than a real identifier, and a translation will break it. - Keep the platform in the name of the locator constant. A constant that both runs share is asserting that two different app-side fields agree, which is a claim someone has to have verified. ## The one-line answer to give On Apple platforms `id`, `name` and `accessibility id` are three doors into one room, so swapping between them is cosmetic; on Android they are separate rooms, so swapping changes what you find. Anyone who says the strategies behave the same way on both platforms has generalised from whichever platform they shipped first.