How would you get one test id into the Android and iOS fields Appium matches across a mixed-stack scouting badge-tracker?

## The decision underneath the plumbing Every form of this question reduces to one choice: **which pair of app-side fields will this application fill, everywhere, so that a suite can address it?** Appium cannot pick for you, because the two platforms publish different fields and no locator strategy matches a field the app left empty. There are two workable pairings, and each has a real price: 1. **`content-desc` on Android with `accessibilityIdentifier` on iOS.** One strategy — `accessibility id` — matches on both, so the locator layer barely branches. The price is that Android's field also carries the announced description, so identity and copy share one slot. 2. **`resource-id` on Android with `accessibilityIdentifier` on iOS.** Identity gets a dedicated field on both sides and copy stays free. The price is two strategies (`id` on Android, `id` or `accessibility id` on iOS) and a UiAutomator2 session setting, because generated values arrive with no package prefix. A lead picks one and writes it down. Teams that never pick end up with both, which is how a suite acquires locators that mean different things on different screens. ## Plumbing it through a mixed stack A real scouting badge-tracker is rarely one technology. The identifier has to arrive in the same fields whichever part of the app drew the screen: - **React Native screens** — `testID` sets `accessibilityIdentifier` on iOS and surfaces as the view id, reported as `resource-id`, on Android. One prop, two fields, plus `accessibilityLabel` separately if the `content-desc` pairing was chosen. - **Flutter screens** — a semantics identifier surfaces as `resource-id` on Android and `accessibilityIdentifier` on iOS, which is why a Flutter app addressed on Android usually runs with `disableIdLocatorAutocompletion` on. - **Compose screens** — a test tag is not reported to the driver by default; UiAutomator2's `mapTestTagToResourceId` puts it under `resource-id`, and there is no equivalent on iOS. - **Hand-written native screens** — the platform fields are set directly in code, and these are the screens most often forgotten, because no shared prop covers them. | | Android | iOS | |---|---|---| | Field the suite addresses | `resource-id` or `content-desc` | `accessibilityIdentifier` | | Attribute in the page source | `resource-id` / `content-desc` | `name` | | Strategy | `id` / `accessibility id` | `id` or `accessibility id` | | Session settings that may be needed | `disableIdLocatorAutocompletion`, `mapTestTagToResourceId` | none | | Silent-failure mode | none — an empty field simply does not match | `name` falls back to the label, so a find still succeeds | ## Where the settings live The two Android settings are matching behaviour for the whole session, not per-locator options. They belong in the Android capability profile beside `appium:automationName`, sent at session start. A test that changes a matching setting mid-run makes one locator string mean two different things inside one session, and the resulting failure looks like flake rather than configuration. The iOS profile needs none of them, which is itself worth writing down so nobody goes looking for a symmetric setting that does not exist. ## Verification, because one platform fails silently The asymmetry that matters most for a rollout is not which field, it is how a mistake announces itself: - On Android, an identifier the app never set produces no match. The failure is loud and lands on the screen that caused it. - On iOS, an empty identifier makes `name` resolve to the element's label, so the find still succeeds against announced text. The screen looks migrated and is not. So absence has to be detected rather than assumed. Make it an explicit step when a screen is onboarded: dump the page source on each platform, confirm the exact string is present in the field the pairing chose, and only then write the locator. Treat a screen that passes on one platform and silently matches copy on the other as unfinished. ## What a lead actually owns here - The pairing, chosen once and applied to every screen regardless of which stack drew it. - The session profiles, so the Android matching settings are configuration rather than test code. - The onboarding step that proves a value landed on both platforms before a suite depends on it. - The hand-written native screens, which no cross-platform prop reaches and which are the usual gap. - The acceptance that the locator layer branches by platform under either pairing, and that pretending otherwise is what produces one suite behaving as two different tests. The answer that lands is not a list of props. It is: choose the field pair, make every stack fill it, put the Android settings in the session profile, and verify per screen because one platform will not tell you when the identifier is missing.