Appium: a WebDriver server that keeps mobile automation out of your app code

The problem Appium solves is app modification, not test authoring

Most mobile automation approaches require you to build a special version of the app, link an automation library into it, or recompile before a test run. Appium's README states the appeal directly: you usually do not have to recompile your app or modify it in any way, because the framework speaks the W3C WebDriver protocol instead of a vendor SDK. That single sentence is the whole product thesis.

The audience follows from it. If you have a WebDriver-based test suite for the web and you now need to drive a native Android or iOS build, Appium lets you keep the client library, the page-object style and the session model you already use, and swap the endpoint. The README frames the project as covering native, hybrid, mobile web and desktop apps, plus IoT platforms, with drivers adding support for each specific platform. Teams that maintain one test framework across several surfaces are the intended users. Teams that want a self-contained tool which installs and immediately drives a phone are not, and the installation section says so plainly: the npm package installs only the core server, which cannot automate anything on its own.

A small core, drivers for platforms, plugins for everything else

The architecture is deliberately split into three extension points, and the README names them: drivers add support for automating specific platforms, clients let you write tests in your language of choice, and plugins extend server functionality without changing server code.

The split between drivers and plugins is not cosmetic. Installed drivers are enabled by default; plugins must be explicitly turned on at server startup, which the README shows as appium --use-plugins=<plugin-name>. If you install a plugin and then wonder why nothing changed, that flag is the reason. Both drivers and plugins are managed through the same extension CLI, with install, list --installed, update, update --unsafe and uninstall subcommands, and both accept --source=npm for packages outside the official set.

The update semantics are worth reading twice. A plain appium driver update will not cross a major version, described in the README as a guard against breaking changes. Crossing it requires --unsafe. That is a sensible default for a test suite you depend on, and it also means a driver can sit on an old major indefinitely unless someone deliberately moves it.

The repository itself is a Lerna monorepo with npm workspaces under packages/*, written in TypeScript, with build orchestration in package.json scripts (build:compile runs tsc -b, build:workspaces runs lerna run build). The npm package appium is the server; the drivers live elsewhere.

Installing Appium and running a first session

Appium installs through npm, and the README notes other package managers are not currently supported. If you are coming from Appium 1, uninstall it first with npm uninstall -g appium, because the README warns that unexpected errors can appear otherwise.

npm i -g appium

After this, the appium binary exists, but it cannot automate a device. Install the driver for your target platform. The README shows the official-driver form and a generic npm form.

appium driver install <driver-name>
appium driver install --source=npm <driver-name>
appium driver list --installed

The list command is the honest check on what your server can actually do. Next, start the server. The README gives the default host and port, and shows that the server subcommand is optional.

appium server
appium --address 127.0.0.1 --port 9000 --base-path /wd/hub

The first command listens on 0.0.0.0 port 4723, which is what a client library expects by default. The second form binds to a specific address, moves the port and sets a base path prefix; the README notes the default prefix is /. Once the server is up, point your client at that URL. The README lists officially supported clients for Java, Python, Ruby and .NET C#, with third-party clients for other languages, and points to the ecosystem pages for the full lists. It does not give a complete worked test in the README itself, so the first real session is a matter of following the client documentation for your language.

Where Appium is the wrong tool

The clearest limitation is stated by the project: the core server automates nothing on its own. If you expect npm i -g appium to be the end of setup, you will be disappointed, and the failure will look like a connection or capability error rather than a missing driver.

Support policy is the second constraint. The README states the Appium team only provides support for the most recent version. Running an older major means you are outside that support boundary, and the migration guides for v1 to v2 and v2 to v3 exist precisely because moving is a project, not a patch. The README does not document a rollback path, so an upgrade that breaks a suite has to be reversed from your own version control and lockfiles.

Parallelism is a third area where the documentation defers rather than answers. The README says Appium supports parallel server processes and parallel driver sessions within a single server process, then tells you to consult the corresponding driver documentation for which mode is optimal and whether the driver supports parallel sessions at all. That is an honest hand-off, but it means you cannot plan a device grid from the Appium README alone.

Finally, the README does not describe a bundled GUI or desktop application. Search interest in an Appium Inspector and an Appium Desktop is real, but the documentation here covers a server CLI, drivers, plugins and clients. If a graphical element locator is a hard requirement for your team, that need is served outside this repository.

Appium against Selenium: same protocol, different problem

Appium is built on the W3C WebDriver protocol, the same protocol Selenium uses, which is why the two are constantly compared and why the comparison is often confused. Selenium drives browsers. Appium drives apps: native, hybrid, mobile web and desktop, per the README's own description.

The practical difference is what sits behind the endpoint. A browser driver is one component that speaks to one browser. Appium is a server that routes commands to whichever driver you installed, and that driver is responsible for translating WebDriver calls into platform-specific automation. That extra layer is what buys you app automation without modifying the app, and it is also what makes driver installation and driver versioning part of your setup rather than an implementation detail. If your testing is entirely web, Selenium is the shorter path. If you need the same session model against an installed app, the protocol is the same but the machinery underneath is not.

Maintenance, licensing and what upgrading costs

The repository is not archived, and the last push was on 2026-09-20. Recent releases include [email protected] and [email protected] on 2026-09-19, alongside @appium/[email protected]. Those are beta tags for a new major line, so the stable version you install today and the version the project is heading toward are not the same thing.

Upgrade cost is structural rather than incidental. Support covers only the most recent version, migration guides exist for v1 to v2 and v2 to v3, and driver updates deliberately stop at major boundaries unless you pass --unsafe. In practice that means your upgrade work is spread across the server and every driver and plugin you installed, and each of those has its own version cadence. Budget for it the way you would budget for a framework migration.

Licensing is Apache-2.0, declared in both the README badge set and the repository package.json. That is a permissive licence, and it is the same licence the project applies to its own monorepo. It says nothing about the licence of third-party drivers and plugins you install from npm, which are separate packages with their own terms; check those individually. This is a description of what the repository states, not legal advice.

Editorial conclusion

Adopt Appium if you already have a WebDriver-shaped test stack and need one protocol for Android, iOS, macOS and Windows, and you accept that every platform capability arrives through a separately installed driver. Do not adopt it if you want a single install that automates a device, or if you need a GUI; the repository ships a server CLI and documentation, and the README does not describe a bundled desktop application. Before writing tests, verify three things: that the driver for your target platform is installed and enabled, that your client library is one of the officially supported four or a third-party equivalent, and that you have read the migration guide for the major version you are leaving. Start with appium driver list --installed, because that command is the fastest way to discover that the server you just installed cannot touch a device.

Frequently asked questions

Official sources

1. appium/appium on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases