Q7 of 26 · Mobile QA
How does Appium's client–server–driver architecture work end to end?
Short answer
Short answer: Your test code (client) sends W3C WebDriver JSON commands to the Appium HTTP server. The server routes each command to the platform driver (UIAutomator2 or XCUITest), which translates it into native automation framework calls on the device and returns the result back up the chain.
Detail
Three layers, clear responsibilities:
Client — your test code (WebdriverIO, Java AppiumDriver, Python client). It creates an HTTP session with the Appium server, sends commands as JSON over HTTP (e.g. POST /session/{id}/element), and receives results. The client doesn't know anything about the device — it speaks pure W3C WebDriver protocol.
Appium server — a Node.js HTTP server. It validates the session capabilities, loads the appropriate driver plugin, and proxies WebDriver commands to the driver. In Appium 2 the server is a thin router; all platform logic lives in the driver.
Driver — platform-specific plugin installed separately (appium driver install uiautomator2). UIAutomator2 installs a helper APK on the Android device that communicates with the Android UIAutomator2 testing framework. XCUITest communicates with Apple's XCUITest framework via XCTest. Each driver translates WebDriver protocol commands into native calls, executes them on-device, and returns structured responses.
This separation is why Appium can support iOS and Android with the same client code — the protocol is identical, only the driver plugin changes. It also means driver bugs are isolated; updating the UIAutomator2 driver doesn't affect the XCUITest driver.