In Appium, which four tiers sit between a test's findElement call and the app under test?

## One call, four owners A test in a fuel-card expense suite asks for the receipt-upload button by accessibility id and gets an element reference back. That one line crosses four separate pieces of software, each shipped by a different package, each with its own log and its own failure modes. Appium's architecture *is* that split, and the reason mobile automation feels heavier than browser automation is that two of the four tiers have no equivalent in a browser setup. ## Tier one — the language client The client (`java-client`, the Python client, and the other bindings) is a library linked into your test process. It turns a method call into an HTTP request against a server URL and turns the JSON response back into an object or an exception. It holds no device state: the element reference it hands you is a string minted further down the stack, and it means nothing to the client itself. ## Tier two — the Appium server `appium` is a Node process. It owns the HTTP route table, session creation and teardown, the session registry, the plugin chain and the server flags such as `--base-path`, `--allow-insecure` and `--relaxed-security`. What it does not own is any knowledge of a phone. It cannot install an app, tap a coordinate or read a view hierarchy. When a new session is requested it reads the capabilities, selects a driver, instantiates it, and from then on routes every request carrying that session id to that driver instance. ## Tier three — the driver Appium 2 made drivers separately installed extensions rather than code baked into the server, and Appium 3 keeps that model. `appium:automationName` names which extension takes the session — Android's UiAutomator2 driver, Android's Espresso driver, Apple's XCUITest driver, a Flutter driver. Every driver extends `BaseDriver`, which supplies session plumbing, the settings mechanism and the proxy machinery, and each adds its own: - a locator-strategy declaration - an execute-method map, which is where its `mobile:` commands come from - a `newMethodMap`, where a driver re-adds routes the core no longer declares - the platform code that actually talks to the device or to its agent The Android drivers share more than their names suggest. Both `appium-uiautomator2-driver` and `appium-espresso-driver` extend `appium-android-driver`, so `mobile: installApp`, `mobile: activateApp`, `mobile: clearApp`, `mobile: setConnectivity` and `mobile: shell` are inherited from that base rather than declared by either one. Android's UiAutomator2 driver declares mostly gesture and window commands of its own, such as `mobile: swipeGesture`, `mobile: flingGesture` and `mobile: listWindows`. Apple's XCUITest driver carries the largest surface of methods declared in its own repository. ## Tier four — whatever the driver must put on the device The bottom tier is the one browser automation has no analogue for, and it is not the same shape for every driver: | driver | what lands on the device | how the driver reaches it | |---|---|---| | Android, UiAutomator2 | `io.appium.uiautomator2.server` plus the `io.appium.settings` helper app | an HTTP server on the device, over a forwarded host port | | Android, Espresso | a server built from Gradle and installed as a test package | in-process instrumentation, signature-matched with the app | | Apple platforms, XCUITest | `WebDriverAgent`, built with `xcodebuild` or already installed | an HTTP server on the target, over a forwarded host port | | Flutter, the official driver | nothing | a WebSocket to the app's already-running Dart VM Service | ## Why naming the tiers is not trivia It is how you read a failure and how you plan an upgrade: 1. Each tier versions independently. A client, a server, a driver and a device-side agent are four releases, and they drift apart. 2. Each tier produces its own evidence. A client exception, a server log line, a driver log line and the agent's own output are four different artefacts. 3. Capabilities are addressed to a tier. `platformName` and `appium:automationName` decide which driver takes the session; nearly every other `appium:`-prefixed key is understood by that driver, not by the core. 4. The bottom tier can die on its own. A driver that is healthy inside the server process can still be talking to an agent that is gone. A useful habit is to say out loud which tier you are accusing before changing anything. A stale client and an agent that never started both surface as a failing find, and only one of them is fixed by a capability.