Why does a freshly installed Appium server automate nothing until you install a driver?

## The split Appium 2 made Appium once shipped as a single package carrying both the WebDriver protocol layer and every automation backend it supported. Appium 2 broke that apart, and Appium 3 kept the break. What the `appium` package installs today is a **server**: an HTTP service that speaks the W3C WebDriver protocol, hosts an extension system, and matches each incoming session request against whatever backends happen to be present. The backends themselves - the **drivers** - are separate packages you install into that server. **Plugins**, which wrap or add commands, use the same mechanism. The practical consequence surprises anyone whose memory of Appium predates the split: a freshly installed server is complete, correct, and automates nothing. It starts, it answers HTTP, and it refuses every session. ## Installing the driver you actually need The install surface is one subcommand per extension kind: - `appium driver install uiautomator2` adds the UiAutomator2 driver, which automates **Android**. - `appium driver install xcuitest` adds the XCUITest driver, which automates **Apple platforms** - iOS and iPadOS, tvOS, and watchOS on simulators. - `appium driver install espresso` adds the Espresso driver, a second **Android** backend. - `appium plugin install images` adds a plugin; plugins install exactly the way drivers do. - `appium setup mobile` is a convenience preset that installs the mainstream mobile drivers in one command instead of naming each one. A bare short name such as `uiautomator2` works because the CLI knows the official extensions by name. Anything else - a community driver, a fork, a working checkout - is installed by saying where it comes from with `--source`, whose values are `npm`, `github`, `git` and `local`. ## Where an installed extension lives Extensions do not land in your project. They land under **`APPIUM_HOME`**, an environment variable that defaults to `~/.appium`. That directory holds the extension packages and an **`extensions.yaml`** manifest recording each installed extension's name, package, version and source, and the server reads the manifest at startup to decide what it may load. Two rules follow: 1. `APPIUM_HOME` is the unit of isolation - point it elsewhere and you get a different, very possibly empty, driver set. 2. The same value must be in effect for the install *and* for the server start. Installing into the default home and then starting the server with a project-specific `APPIUM_HOME` is the most common 'but I did install it' failure. `appium driver list --installed` prints what the current home holds, and is the first command to run when a session reports that no driver matched. ## What the failure actually looks like Without a matching driver the failure is neither a transport error nor a missing route: `POST /session` exists on a bare server. The request gets as far as capability matching and is rejected because no installed driver claims the requested `platformName` and `appium:automationName` pair. That is useful information - the server is healthy and the extension set is wrong. Check, in order: - The installed list, under the same `APPIUM_HOME` the server process uses. - Whether the server was started with `--use-drivers`, which narrows the active set to the drivers you name. - Whether the installed driver's declared peer dependency matches the server's major line; every current driver declares one against the server package. ## What the extra step buys | | Android suite | Apple-platform suite | |---|---|---| | Driver to install | `appium driver install uiautomator2` | `appium driver install xcuitest` | | Host it needs | any host with the Android SDK's `adb` reachable | macOS with Xcode to build the on-device agent or run simulators | | Second official option | `appium driver install espresso` | none | - You install only the platforms you automate, so a server's footprint matches its job. - Drivers release on their own cadence, independently of the server's. - A third-party or forked driver is a first-class citizen rather than a patch applied to the server. - The set of drivers on a machine becomes something you can state, inspect and reproduce, instead of something implied by the server version. The cost is exactly the step this question is about: nothing automates anything until you say what to install, and a host that has never been told stays a perfectly healthy server that answers every request by refusing it.