In Appium, which driver commands need an Android emulator or Apple simulator, and which refuse one?
answer
- per method, not per platform
- both directions, both platforms
- a shared name proves nothing
- one command throws, session lives
- guard at the seeding helper
basics
~10 sSupport is a property of the individual method, not of the platform. Some commands need a virtual target and some need physical hardware, and both cases occur on both platforms. Check per method.
solid answer
~40 sTreat target-class support as a property of the **method**. On Apple, `mobile: clearApp`, `mobile: setPermission` and `mobile: getPermission` are simulator-only, while `mobile: resetPermission` works on a simulator and on a real device; the condition-inducer methods run the other way and need real hardware. On Android, `mobile: networkSpeed` is measured emulator-only and the emulator-console family goes with it, while most of the Android drivers' surface works on either class. Note that `mobile: clearApp` exists on both platforms with *different* target rules — a name being present says nothing about where it runs. The refusal arrives as an error from that one command mid-run, not as a rejected session, so guard virtual-only steps at the suite boundary.
go deeper
Know that some commands only work on an emulator or simulator and others only on real hardware, and that you look this up per command rather than guessing from the platform.
Be able to give examples in both directions on both platforms, and explain why a command existing on Android and on Apple says nothing about where each of them actually runs.
Show the operational reasoning: the refusal arrives mid-run from one command, so gated calls belong in named seeding helpers guarded by what the lane knows about its own target class.
Own the coverage consequence. Every gated step narrows where a suite can run, so decide deliberately which cases may be virtual-only and make that gap visible rather than incidental.
## Support belongs to the method, not the platform The tempting shortcut is "Apple simulators are limited" or "emulators can do more". Both are wrong in the same way: they attach the restriction to the platform when it actually attaches to the individual command. The honest formulation is per method, and it has four cells rather than two — for each platform, some methods need a virtual target, some need physical hardware, and most need neither. That matters because a hearing-aid fitting suite does not fail platform-wide. It fails one step, on one lane, at the moment that step runs. ## What a virtual target unlocks Some capability exists only because the device is software you control: - On Apple, `mobile: clearApp` is supported on simulators only, and it is real there — "iOS has no way to clear an app" overstates it, while "there is one and it only works on a simulator" is the fact. - On Apple, `mobile: setPermission` and `mobile: getPermission` are simulator-only, so seeding a permission state before a fitting session is a simulator-lane move. - On Apple, `mobile: simctl` needs a booted simulator by definition, since it invokes simulator-control tooling. - On Android, `mobile: networkSpeed` is measured emulator-only, and the emulator-console family (`mobile: execEmuConsoleCommand`, `mobile: gsmCall`, `mobile: sendSms`, `mobile: powerCapacity`, `mobile: sensorSet`) rides a channel a physical phone does not have. ## What a virtual target refuses The traffic goes the other way too, which is the half people forget: - On Apple, `mobile: enableConditionInducer`, `mobile: disableConditionInducer` and `mobile: listConditionInducers` are a real-device facility, not a simulator one. - Anything that depends on genuine hardware behaviour — real radios, real sensors, real power and thermal behaviour — is not something a virtual target can be commanded into. So a virtual target is neither a subset nor a superset of a real one. It is a different set, and the difference runs in both directions on both platforms. ## The trap of a shared name `mobile: clearApp` exists on Android and on Apple. The name being present on both is worth nothing: on Android it clears the app's stored state on any target, and on Apple it is simulator-only. The same lesson applies to permissions, where the split is not "the Apple permission methods are simulator-only" but *this* method is and *that* one is not — `mobile: resetPermission` works on both classes of Apple target. **Say which method, not which platform.** ## How the refusal actually arrives This is the operational half of the answer, and it is what separates a senior answer from a memorised list: 1. The session starts normally. Nothing in the capability block declares which target-class-gated methods you intend to call, so nothing is validated up front. 2. The step runs and that one command throws. The session is still alive. 3. The failure is reported as a test failure, usually somewhere in setup, and looks like a product bug until someone reads the message. The practical consequence: a virtual-only step buried in a shared setup helper will fail an entire hardware lane one test at a time, with a stack trace pointing at your fixture rather than at the target class. ## Making a suite survive it - Decide per step, not per platform, whether it can run on the lane in front of it. - Keep target-class-gated calls in named seeding helpers, never inline in a test body, so there is one place to guard. - Drive the guard from the lane's own configuration — the lane knows whether it is an emulator, a simulator or hardware — rather than from a catch block that swallows the error. - Prefer a command that works everywhere when one exists; reach for the gated one only when nothing else produces the state. - Record which cases are virtual-only, so their absence from a hardware run is a known gap rather than a silent one. - When a command's support is unclear, check the driver's own reference for that method rather than generalising from a neighbouring one. ## Why this is the shape of the whole subject Every divergence here has the same structure: the same word covers two mechanisms, or the same command covers two support rules. The virtual-target question is that structure at its clearest, because the Apple answer and the Android answer are independently true and neither generalises. A candidate who says "check the method, on that platform, for that target class" has understood it; one who ranks the two platforms has not.
- How does the failure present when a simulator-only command runs on real Apple hardware?That single command throws while the session stays alive, so the run continues into whatever the test does next. Nothing is validated at session start, because capabilities never declare which gated methods you intend to call. Expect it to look like a setup failure inside your own fixture rather than a target-class problem.
- Is a virtual target simply a reduced version of a real one?No. It is a different set of capabilities, not a subset. A simulator or emulator unlocks things hardware cannot be commanded into — cleared app state, seeded permissions, faked telephony — and refuses things that need real hardware, such as Apple's condition inducers. Reasoning by ranking the two target classes gives wrong predictions in both directions.
saying these in an interview costs you the question
- Says every Apple permission method is simulator-only
- Treats a virtual target as a strict subset of hardware
- Assumes a shared command name implies shared support
- Expects the session to be rejected at start instead of mid-run
- Wraps every gated call in a catch that hides the error