In Appium, does every driver have to install an agent on the device?

## The fourth tier exists only if the driver needs it The tidy picture of Appium — client, server, driver, agent — is right three times out of four. The bottom tier is whatever the selected driver has to place on the device in order to do its job, and one common driver places nothing there at all. Saying *the driver installs an agent on the device* as a general truth about Appium is the mistake this question exists to catch. ## What each driver deploys | driver | what it deploys | how it gets there | |---|---|---| | Android, UiAutomator2 | `io.appium.uiautomator2.server`, plus the `io.appium.settings` helper app | installed and started by the driver before commands flow | | Android, Espresso | a server built from the app's Gradle project, installed as a test package | built then installed; app and test package must share a signature | | Apple platforms, XCUITest | `WebDriverAgent` | built with `xcodebuild` on a macOS host, or already installed on the target | | Flutter, the official driver | nothing | it attaches to the app's already-running Dart VM Service over a WebSocket | The Flutter row is not a technicality. The official Flutter driver speaks the Dart VM Service Protocol with the `ext.flutter.driver` extension, so the thing it talks to is part of the app process, not something Appium put on the handset. ## What deploying an agent costs Where the fourth tier does exist, it drags real consequences up the stack: - **It is a separate deployable with its own lifecycle.** Installed, started and reachable are three different states, and the agent can die mid-run without the driver dying with it. - **It versions on its own schedule.** The agent on the device can be older than the driver that installed it, so behaviour can differ from what the driver's own code suggests. - **It needs an address.** Each session's agent is reached over a host-side port, which is why parallel runs have to think about ports at all. - **It has to be trusted by the platform.** Apple's XCUITest driver needs `WebDriverAgent` signed for the target; Android's Espresso driver needs its test package to share a signature with the app under test. - **It is a first-class failure site.** Plenty of sessions that never reach a single find failed because the agent did not come up. ## Where the agent's requirements reach back up the stack The clearest example is host choice. Building `WebDriverAgent` needs macOS with Xcode, and Apple simulators only run there, so a macOS host is required for the ordinary Apple path. A non-macOS host can still drive a recent Apple *real device* if the agent is pre-built or already installed, with automatic device selection and the usual `xcodebuild`-based startup strategy off the table. That is a tier-four requirement dictating where tiers two and three are allowed to run — exactly the kind of coupling that surprises a team porting a fuel-card expense suite onto a Linux build agent. Android has the mirror-image version of the same story. There is no provisioning profile, but there is still signing: the drivers can re-sign an app when a certificate check fails, and Android's Espresso driver requires the app and its test package to match. The honest framing is not *one platform signs and the other does not* but *what is signed differs*: Apple signs the test agent so the OS will run it, Android signs the app so instrumentation can attach to it. ## What installing nothing costs instead The Flutter route trades one constraint for another. The official Flutter driver puts nothing on the device, but it needs the app under test to import the test package, so the build it drives is not the build you would ship as-is. A community alternative built on Flutter's `integration_test` exists. And there is a third path that skips the Flutter drivers entirely: because a Flutter widget identifier can surface as a native identifier on Android and on Apple platforms, a native driver can drive a release Flutter build without either Flutter driver. ## The rule to carry away Ask what the selected driver needs on the device before you reason about anything below the driver tier: 1. If it deploys an HTTP agent, expect an install step, a port, a signing or trust requirement and an independent failure mode. 2. If it attaches to something already running in the app, expect a build-time requirement instead. 3. Either way, name the driver when you describe the behaviour — the shape of the bottom tier is a per-driver fact, never a fact about Appium as a whole.