In Appium, what identifier does appium:udid carry on Android and on Apple platforms?

`appium:udid` is the one selection key spelled the same way on both platforms, and it is the one whose value is never the same kind of thing. That combination — shared name, different identifier — is why it is worth learning as a pair of facts rather than as one. ## Where the key comes from `appium:udid` is a core Appium capability. It sits on the base constraint list that every driver inherits, alongside `platformName`, `app`, `platformVersion`, `automationName`, `noReset` and a short handful of others. `appium:deviceName`, by contrast, is not on that list at all — it is declared by the Android drivers and by the XCUITest driver individually. So when two platforms both accept `appium:udid`, they are accepting the same core key, which is exactly why the name does not vary. Like every non-W3C name in a session request it travels with the `appium:` prefix; `platformName` is the bare W3C name in this group. ## What it holds on Android On Android the value is the serial adb reports for the target. That covers both kinds of target: - a real handset, whose serial the device carries and adb echoes back; - a running emulator, which appears on the adb side with its own name once it is up. One consequence follows immediately. On Android a serial identifies a target that is *running*. An emulator that has never been started has no serial to point at, which is why Android also has `appium:avd`, a key that names the AVD definition on the host instead of a runtime identity. ## What it holds on Apple platforms On Apple platforms the value is the device UDID — the identifier the platform itself uses for that hardware. It is the key that addresses a real device, which the XCUITest driver reaches through `devicectl`. Simulators travel a different path: the driver reaches those through `simctl`, and a simulator is normally named descriptively, by `appium:deviceName` with `appium:platformVersion`. It is also worth noting that the XCUITest driver is not exclusively an iPhone driver — it targets Apple platforms more broadly, on simulators and on real hardware. The identity key does not change shape across them. ## Same name, two vocabularies | | Android | Apple platforms | | --- | --- | --- | | what the value is | the serial adb reports | the device UDID | | what it names | a real handset or a running emulator | a real device | | the descriptive alternative | `appium:avd`, the AVD name | `appium:deviceName` with `appium:platformVersion` | The practical rule: an `appium:udid` value is never portable between lanes. Copying an Android worker's capability map into the Apple lane and changing `platformName` produces a request that names a target which does not exist on that side. ## Why the dental-recall suite cares The dental-recall booking app runs a rack of Android handsets in the lab and a small set of enrolled Apple devices. Both lanes want the same thing — this run goes to that machine and no other — and both express it with `appium:udid`. What differs is where the value comes from and how it is maintained: - The Android values come from the serials the rack reports, and they change when hardware is swapped in or out. - The Apple values come from the UDIDs of the enrolled devices, and they change when the enrolled set changes. - Neither list can seed the other, and a value that has gone stale produces a request naming a machine that is not there. ## Identity beats description The deeper reason to prefer `appium:udid` where the target is a real device is that it is an identity, not a description. 1. A serial or a UDID matches exactly one target. 2. A model name matches every target of that model. 3. A model name plus a runtime matches every simulator of that model on that runtime. Descriptions are convenient and readable, and they are the right tool for a virtual target that has no runtime identity yet. But when several machines could satisfy the description, a description leaves the choice open, and a suite that cannot say afterwards which machine ran is a suite whose device-specific failures cannot be chased. That is the trade `appium:udid` exists to close, on both platforms, in two different alphabets.