In Appium, why does mobile: networkSpeed need an Android emulator while iOS condition inducers need a real device?

## The restriction is not arbitrary Both commands look like the same feature from a test's point of view — make the link bad — so the opposite hardware requirements read as an inconsistency until you look at what each one is actually driving. Neither driver implements network degradation. Each one reaches for a facility that already exists on exactly one kind of target, and inherits that target's limits. ## Android: mobile: networkSpeed configures an emulated modem `mobile: networkSpeed` is declared by **`appium-android-driver`**, the base driver behind both the UiAutomator2 and the Espresso Android drivers. What it configures is the **emulator's simulated modem** — the link profile the virtual device pretends to have. A physical Android handset has a real radio with a real carrier attached and no such dial for a driver to set, which is the whole reason the command is documented as emulator-only. Two spelling and scoping points travel with it: - The name is `mobile: networkSpeed`. **`setNetworkSpeed` does not exist** in any Appium driver; it is one of the most common misremembered identifiers on this subject. - It sits with a family of emulator-facing commands in the same package — `mobile: gsmSignal`, `mobile: gsmVoice`, `mobile: gsmCall`, `mobile: execEmuConsoleCommand` — all of which configure an emulated device rather than real hardware. ## Android's other lever is not restricted the same way It is easy to over-generalise from `networkSpeed` and conclude that all Android network control is emulator-only. It is not. `mobile: setConnectivity` — the command that toggles wifi, mobile data and airplane mode, with `mobile: getConnectivity` reading the state back — changes real device state and is not confined to an emulator. So on Android the picture is two commands with two scopes: **switch the radios anywhere, throttle the link only on an emulator**. ## Apple: the driver switches on something the platform owns The XCUITest driver exposes `mobile: enableConditionInducer`, `mobile: disableConditionInducer` and `mobile: listConditionInducers`. The verb *induce* is doing the work. The driver does not model a lossy link; it asks the operating system to turn on one of its own condition profiles, naming a condition and one of that condition's profiles — identifiers you get from `mobile: listConditionInducers` rather than from memory. That facility is part of the device software on real Apple hardware. A Simulator is a process running on the Mac and uses the Mac's own networking, so there is no per-device condition to induce and the command is documented as real-device only. Nothing in the driver could paper over that: the feature it is calling is simply not present. ## The inversion, side by side | Question | Android | Apple | |---|---|---| | throttle command | `mobile: networkSpeed` | `mobile: enableConditionInducer` | | what it drives | the emulator's simulated modem | a condition profile the OS provides | | where it runs | emulators only | real devices only | | radio toggle | `mobile: setConnectivity`, not emulator-restricted | none in the driver | | discovery | not applicable | `mobile: listConditionInducers` | ## What it means for a suite Suppose the parking-permit renewal app must survive a slow link while the renewal is submitted. The two throttled runs cannot be scheduled against the same class of target: 1. The Android throttled run needs an **emulator** in the pool, because a real handset will reject `mobile: networkSpeed`. 2. The Apple throttled run needs a **real device**, because a Simulator has no inducer to enable. 3. Any Android step that only needs the radios off — not slowed, off — can run anywhere, because that is `mobile: setConnectivity`. The failure mode when this is not planned for is quiet rather than loud. A suite written on an Android emulator and an Apple real device passes; the same suite moved onto an Android handset and an Apple Simulator throws on both throttled cases, and it looks like a driver bug rather than a target mismatch. Write the skip or the routing by target type deliberately, and let the error message say which target the command wanted. ## Traps worth naming - Assuming that because one command is emulator-only, all Android network control is. - Reaching for a condition inducer on a Simulator because the rest of the XCUITest surface works there. - Writing setNetworkSpeed, which verifies against nothing because it exists nowhere. - Describing both platforms in one sentence, which always erases one of the two restrictions.