skip to content

In Appium, an `accessibility id` that finds the stadium turnstile scan button on Android returns nothing on iOS — how do you triage it?

level: seniorimportance: should knowfreq 50%

answer

  1. not a locator bug, a one-sided address
  2. each platform reads its own field
  3. read the Apple name attribute first
  4. caption-shaped value means unset identifier
  5. repair belongs in the build

basics

~20 s

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.

solid answer

~40 s

Start from what each platform compares. Android matched `content-desc`; the Apple platform would have to match `name`, which is the element's `identifier` or, when empty, its `label`. So work in that order: confirm the token really is the Android description and not something you assumed, then read the Apple element's `name`. Three outcomes: `name` is a different token, so the two builds drifted; `name` equals the visible caption, so the identifier is unset and any earlier Apple pass was a fallback match; or the element carries no usable name at all, so the address exists only on Android. The fix belongs in the build that is missing the field — swapping the Apple half to another strategy makes the step green while leaving one control with two unrelated addresses.

go deeper

for a junior

Learn the first move rather than the whole method: read the element's field on each platform, content-desc on Android and name on Apple platforms, before changing a single character of the locator.

for a middle

Be able to name the three causes of a one-sided address and say which value of the Apple name attribute points at each. That mapping is what turns a vague investigation into a short one.

for a senior

Demonstrate the full order, including the second-language check, and argue why the repair belongs in the build. Be explicit that the passing platform may have been matching a caption rather than an address.

for a principal

Own the systemic angle: how the team keeps one shared address honest across two builds and two repositories, what evidence proves it is honest, and how drift is surfaced when it lands rather than a release later.

## Frame the failure correctly before touching anything A locator that works on one platform and not the other is almost never a locator-syntax problem, because the request is identical on both. `accessibility id` is a shared strategy over two unrelated app-side fields: - On Android, the UiAutomator2 driver compares your string with the element's `content-desc`. - On Apple platforms, the XCUITest driver compares it with the element's `name`, which is the `identifier` when non-empty and otherwise the visible `label`. So the question to answer is not *why is my locator wrong* but *which of the two fields does not carry the token* — and, if one does carry it, whether it carries it for the right reason. ## A triage order that converges fast 1. **Pin the exact string.** Compare the token in the test with the token in the build, character for character, in both places. Half of these investigations end here, on a stray difference nobody looks at twice. 2. **Confirm the Android side really matched the description.** Read the matched element's `content-desc` on Android. Knowing the token genuinely lives there tells you the Android half is the reference, not a lucky match. 3. **Read the Apple element's `name`.** This is the decisive step, and everything after it is bookkeeping. 4. **Interpret what `name` holds.** An unrelated token means the two builds drifted apart. A value identical to the visible caption means the identifier is empty and you are looking at the label fallback. Nothing usable means the address was never set on that platform. 5. **Check a second display language, if the product ships one.** A caption match changes with the language; an identifier match does not. One run separates them. 6. **Only then decide where the repair belongs** — in the build that is missing the field, or in the suite if the control genuinely cannot carry a shared address. ## The three causes, and how each one looks | Cause | What the Apple `name` shows | What it means for the suite | |---|---|---| | Address exists only on Android | no usable value | one build was never given the token | | The two builds drifted | a different token | the shared address quietly became two addresses | | Identifier unset, label present | the visible caption | earlier Apple passes were caption matches, not proof | The third row is the one that reframes the whole investigation, because it means an Apple-platform lane may have been green for months on an address that was never really there. That is the specific hazard of this strategy and the reason a senior answer does not stop at *set the identifier*. ## The repair that looks like a fix and is not The fastest way to turn the Apple lane green is to point it at some other addressing scheme for that one control. Resist it, for reasons worth being able to state: - It leaves one control with two unrelated addresses, which is the two-suites-in-one-name outcome the shared address exists to prevent. - It hides the app-side omission, so the next control with the same omission is investigated from scratch. - The replacement is usually a platform dialect that the Android half cannot use, so the divergence spreads instead of closing. - A future reader cannot tell the workaround from a deliberate design choice. The honest repair is to have the missing field populated in the build that lacks it, using a token that could never be product copy, and then collapse both platforms back onto the one constant. ## Making the next one cheaper After the immediate fix, spend a little on making the failure mode visible rather than exploratory: - Choose token shapes that are self-evidently not captions, so a successful Apple match is self-diagnosing. - When a control matters, assert what you matched — comparing the element's `name` with the token you searched for converts a silent fallback into a failing check. - Run the cross-platform lanes against a matched pair of builds, so drift is caught when it lands rather than a release later. - Record the cause when you close one of these, because *worked on Android, nothing on the Apple platform* has three causes and the team will meet all three. ## What an interviewer is listening for A weak answer starts changing locators. A strong one states the divergence first, moves straight to reading the Apple element's `name`, and can distinguish the three causes by what that attribute holds. The strongest adds the uncomfortable half: the failing platform may be the honest one, because the platform that passed might have been matching a caption all along.

  • The Apple element's `name` turns out to equal the button's visible caption. What is your conclusion?
    The identifier is empty and `name` fell back to the `label`. Any earlier pass on that platform matched product copy, not an address, so it was never evidence the build carried the token. Treat the control as unaddressed on that platform and have the identifier set.
  • When is it legitimate to give a control different addresses on the two platforms?
    When the control genuinely cannot carry a shared field — a platform-specific system surface, say — and the divergence is deliberate and recorded. As an unplanned reaction to a red step it is a workaround: it hides a missing app-side field and spreads platform-specific addressing through the suite.

saying these in an interview costs you the question

  • Starts rewriting locators before reading either platform's field.
  • Concludes the Apple build is fine because the Android lane passes.
  • Assumes a longer wait will make the missing address appear.
  • Fixes the failing platform with a dialect the other one cannot use.
  • Ignores that an earlier passing run may have matched a caption.
  • Never checks whether the two builds carry the same token.