Can Appium drive a real iPhone from a Linux or Windows host, and what does that give up?

## The short answer, and why the limits matter more than it Yes — the XCUITest driver documents **limited support for Windows and Linux host machines**. The interesting part is the list of things that stop working, because each one moves work somewhere else rather than removing it. Teams reach for this to avoid buying and maintaining Mac capacity for every parallel worker, and the arrangement only pays off if the constraints are designed around rather than discovered mid-migration. ## What a non-macOS host can and cannot do - **Only real devices are supported.** Apple simulators can only be run on macOS, so a Linux or Windows host is a hardware-only host by definition. - **The real devices must be on a recent iOS or tvOS release.** Older hardware does not support the mechanism the driver uses to reach a device off macOS. - **Automatic device selection is not supported.** The run has to be pointed at a particular device rather than letting the driver find one, which pushes device bookkeeping into the harness. - **The default agent start-up strategy is not supported.** That strategy builds **WebDriverAgent** with Apple's build tooling, and the build tooling is macOS-only, so the agent must already be built, signed and installed on the device. Read together, those four say the same thing in four ways: **a non-macOS host can drive an Apple device, but it cannot prepare one.** Preparation stays on a Mac. ## The estate that falls out of it The practical shape is a split: 1. A **Mac with the Apple toolchain** builds and signs the agent, and installs it onto each device on the bench. This is periodic work — a new signing identity, an added device, an updated agent — not per-run work. 2. **Cheaper hosts** run the sessions against those prepared devices, each addressing a device explicitly. 3. Anything **simulator-shaped** stays on macOS, so a suite that mixes virtual and physical Apple targets still needs Mac capacity for half of itself. The risk this design carries is **agent staleness**. Because nothing on the Linux host rebuilds the agent, an expired credential or an agent that predates a device update turns into a fleet-wide failure that no host-side change can fix. That is the trade you accept: fewer Macs, but a manual refresh step with its own owner and its own schedule. ## The Android half of the same suite There is no matching asymmetry. Android hardware is driven through platform tools that run on macOS, Linux and Windows alike, and the phone neither knows nor cares which operating system the host runs. A run that drives a recycling-collection reminder app across both platforms therefore has a lopsided topology: the Android workers can live anywhere, while the Apple workers depend on a Mac having done its preparation first. Saying that out loud is what separates a considered answer from *you need a Mac for iOS*. | Concern | Non-macOS host, Apple devices | Any host, Android devices | | --- | --- | --- | | Virtual targets | not available — simulators are macOS only | emulators run wherever the tooling does | | Device selection | must be explicit | driven by the platform tools as usual | | Agent preparation | done in advance on a Mac | done by the driver at session time | | Device release requirement | recent iOS or tvOS only | no host-driven restriction | ## How to decide - **Count the Macs the arrangement still needs.** If the answer is one, it is a single point of failure for the whole Apple fleet; if it is zero, someone has misread the constraint. - **Name the owner of the agent refresh.** An unowned periodic step becomes an outage the first time a credential lapses. - **Check the device inventory against the release requirement** before committing, because older handsets on the bench are excluded from this arrangement entirely. - **Keep the split visible in the harness**, so a failing Apple worker is diagnosed as *this device was never prepared* rather than as a flaky test. ## What this does not cover - **Which capability points a session at an already-installed agent** is configuration detail owned elsewhere; the host constraint is the subject here. - **Renting hardware** so the host question goes away is a purchasing decision belonging to a different subject. - **Diagnosing an agent that fails to start once everything is in place** is start-up triage, not a host-platform question. The answer an interviewer is listening for is not yes or no. It is that the host choice **relocates the Apple-specific work rather than removing it**, and that you know which work moves.