In Appium, what does appium:avd name on Android, and what names an Apple simulator?

Every fleet has targets that exist on the host before anything is running: an Android Virtual Device that is defined but not booted, a simulator that is installed but not launched. Naming one of those is a different problem from naming a device that is already attached, because there is no runtime identity yet to point at. Both platforms solve the problem, and they solve it with different keys and a different number of them. ## Android: one key, appium:avd `appium:avd` carries the name of an Android Virtual Device. That name is a host-side definition rather than a runtime identity, which is precisely why the key exists. `appium:udid` would need the serial adb reports, and a serial belongs to a target that is running; naming the AVD lets a request describe a target that does not exist yet as a running thing. `appium:avd` is Android's alone. There is no Apple counterpart to it, and writing it into an Apple lane names nothing. ## Apple platforms: a pair, and both halves matter An Apple simulator is named by two keys together: - `appium:deviceName` — the model. - `appium:platformVersion` — the runtime. The XCUITest driver reaches simulators through `simctl`, where a simulator is identified by exactly that combination, so the capability pair maps onto the platform's own model. Send the model alone and the request is under-specified, because one model is normally installed against several runtimes; which of them you get is then not something the request decided. ## The shape is the same, the surface is not | | Android emulator | Apple simulator | | --- | --- | --- | | key or keys | `appium:avd` | `appium:deviceName` with `appium:platformVersion` | | what the value describes | an AVD definition on the host | a model and a runtime | | number of keys required | one | two | | identity or description | description | description | Both are descriptions rather than identities, and that is the deeper point. A description is only as precise as the vocabulary it draws on. Two AVDs with different names are separable; two simulators of the same model on the same runtime are not separable by that pair, however the request is written. ## The dental-recall lanes 1. On the Android build machine, the dental-recall emulator lane sets `platformName`, `appium:automationName` and `appium:avd`, naming the AVD that carries the seeded appointment data. 2. On the Mac, the simulator lane sets `platformName`, `appium:automationName`, `appium:deviceName` for the model and `appium:platformVersion` for the runtime. 3. Neither lane can borrow the other's key. Putting `appium:avd` into the Apple lane names nothing; putting `appium:deviceName` alone into the Android lane names nothing either, since that key does not select there. ## When the wrong key is sent - An Apple lane carrying `appium:avd` has not named a simulator, and whatever runs is not the target the author had in mind. - An Android lane carrying `appium:deviceName` instead of `appium:avd` looks correct, reads correctly, and selects on neither key. - An Apple lane carrying `appium:deviceName` without `appium:platformVersion` becomes ambiguous the moment a second runtime is installed on that Mac — which happens routinely, and silently. - A run whose target key was wrong still produces results, which is why this class of mistake is usually found long after it is made. ## What these keys do not decide - They do not decide how the virtual target is brought up, what arguments it starts with, or how long the run waits for it. Those are separate capabilities and a separate subject. - They do not decide which models and runtimes the suite ought to cover; that is a coverage decision rather than a capability. - They do not, on Android, make `appium:deviceName` meaningful. Adding `appium:avd` beside it does not promote the other key; it takes over the job that key looked like it was doing. ## The mechanic worth being able to explain Ask why Android needs a dedicated key and Apple does not, and the answer is about where the definition lives. Android's virtual targets are named artefacts on the host, each with a name of its own, so a single name is a complete handle. Apple's simulators are enumerated as a model crossed with a runtime, so a complete handle takes two values. Neither is better; they are two vocabularies, and a capability map has to speak the right one per lane. That is the level of answer a middle-tier interview is after: not only which key goes where, but why the key count differs, and what the difference costs when a run has to be pinned to one virtual target and proved to have gone there.