Appium java-client and its Selenium compatibility

Version 11 dropped to selenium-api and moved the floor

The v10 to v11 migration section changes dependency and version requirements.

Since v11 the client depends on `selenium-api` only. The minimum supported Selenium version is `4.50.0`. The minimum supported Appium server version is 3.

Depending on `selenium-api` only is the significant part. That narrows the client's declared Selenium API dependency.

The migration path is documented rather than left to inference. There is a `docs/v10-to-v11-migration-guide.md`, and the README highlights that it includes an OpenRewrite recipe which fixes most of the imports automatically. That is a real time saver for a large suite, since the changes here are largely import rewrites.

The same documentation-first pattern covers the earlier jumps. There is a v9 to v10 migration guide, a v8 to v9 guide which notes that since v9 the client only supports Java 11 and above, and a v7 to v8 guide which says that version 8 had several major changes that might require updating client code.

These migration guides document compatibility changes, and the most recent one includes an import-rewriting tool. That is the normal shape for a binding whose upstream does not version cleanly, which is the subject of the compatibility matrix.

The compatibility table is the documentation that matters

The compatibility matrix maps client versions on the left to Selenium client versions on the right, and reading it tells you several things at once.

The current row is `11.0.0` paired with Selenium `4.50.0`, a single version. Below it, `10.1.1` supports eight Selenium versions from `4.42.0` through `4.49.0`, `10.1.0` supports `4.40.0` and `4.41.0`, and `10.0.0` supports five from `4.35.0` through `4.39.0`. The older rows continue down through `9.5.0` paired with `4.34.0`, `9.0.0` supporting three versions of which `4.16.0` is annotated as partially corrupted with a link to an upstream Selenium issue, and down to `8.2.1` supporting `4.5.0` through `4.6.0`.

The pattern is that support widens on patch releases and narrows at a major boundary. That is consistent with the stated reason for the table's existence, given in a section headed why is it so complicated: the Selenium client does not follow Semantic Versioning, so breaking changes might be introduced even in patches, which requires the Appium team to update the Java client in response.

The table records the Selenium versions listed as compatible with each client version.

Two cells carry annotations rather than plain versions. `9.2.1` is marked with two known issues by issue number, and the row listing `8.5.0` through `8.6.0` marks Selenium `4.12.1` as having a known issue by issue number too. Both are recorded rather than hidden, which is the useful behaviour: if you are on one of those pairs, the failure mode is already documented.

Pinning Selenium yourself, because the range is open

The dependency declaration is deliberately loose, and the README explains both why and what to do about it.

Appium Java Client declares its Selenium dependencies using an open version range, which is handled differently by different build tools. Sometimes users may want to pin the Selenium dependencies for various reasons, and a linked issue is given as the reason. The documentation pointer is `docs/transitive-dependencies-management.md`, an article on establishing a fixed Selenium version for a Java test framework.

An open range in a test dependency is unusual and the reason is upstream. Because Selenium ships breaking changes in patch releases, a bounded range would exclude valid combinations and an exact version would exclude valid combinations faster. The Appium team chose to declare what they have tested, and the compatibility table documents it, leaving the pinning to you.

The practical consequence is that two developers on the same project can resolve different Selenium versions without anything looking wrong. That is worth handling deliberately, and the article on transitive dependency management is the place the project points you.

The dependency coordinates themselves are unremarkable. For Maven, `io.appium:java-client` with a `<scope>test</scope>`, and for Gradle, `testImplementation 'io.appium:java-client:${version.you.require}'`. The test scope is the right convention for a test binding and worth keeping so it does not leak into your application classpath.

The Maven form the README gives is:

<dependency>
  <groupId>io.appium</groupId>
  <artifactId>java-client</artifactId>
  <version>${version.you.require}</version>
  <scope>test</scope>
</dependency>

The server compatibility rule is narrower than it looks

The Appium Server Compatibility section states a rule that is easy to skim and important to plan around.

A major release of the client guarantees support only for the Appium server API of the major server version current at the time of the release, and of the previous major version. Endpoints and commands removed or deprecated earlier in the server may not be supported any more. The worked example: if Appium 4 is current, the API that existed in Appium 2 and was removed or deprecated in Appium 3 is not guaranteed to work.

So the guarantee is a moving two-version window, and it is anchored to the moment of the client release rather than to your server. A client released when Appium 3 was current covers Appium 3 and 2. That is a narrower contract than any Appium 2 or later, and it means an Appium server upgrade can require a client upgrade, not just an app code change.

The interaction with the v11 floor makes this concrete. v11.0.0 requires an Appium server 3 or later and Selenium 4.50.0, so an organisation still on an Appium 2 server cannot move to the current client line without moving the server at the same time. That is a coordinated upgrade across the test stack, and it is the kind of thing to discover during planning rather than during a release.

Dedicated driver classes, and JitPack for pre-release builds

The binding is more than a WebDriver client, and the drivers section lists dedicated classes per platform.

UiAutomator2 and Espresso are covered by `AndroidDriver`, XCUITest by `IOSDriver`, with the source paths given into the repository tree. The topic list additionally names macos and windows alongside android, ios and selenium, which is the platform coverage a cross-platform suite expects from a library in this position.

The repository documents driver-specific classes for supported Appium drivers.

The stable and pre-release installation paths differ in a way that matters for CI. From Maven Central the coordinates are `io.appium:java-client`. For a build that needs a change before it is published, the project points at jitpack.io, and the coordinates change with them: the groupId becomes `com.github.appium`, the artifact stays `java-client`, and the version is the latest commit ID from the master branch. Both Maven and Gradle snippets are given, and the Gradle one requires adding the JitPack repository to the root build file.

Using a commit ID as a version is worth understanding rather than copying casually. It is reproducible in the sense that a given commit always resolves to the same build, but it is not a release, so nobody has declared it supported and it will change under you when you move the commit ID. For a CI experiment that is fine; for a suite the team depends on, Maven Central is the safer coordinate.

The repository also carries `jitpack.yml` at the root, which is what tells JitPack how to build the project, alongside `build.gradle`, `gradlew`, `settings.gradle` and a `config/` directory, and a `selenium-bridge/` directory.

Licensing, maintenance and what to check first

Licensing is Apache-2.0, with a `LICENSE` file and a `NOTICE` file at the repository root. The project uses the Apache-2.0 license.

Maintenance is current. The repository is not archived, the last push was on 2026-10-15, two days before today, and releases are frequent: v11.0.0 on 2026-10-07, v10.1.1 on 2026-04-20 and v10.1.0 on 2026-03-11. The ten-month gap between the 10.x line and 11.0.0 matches the length of the change described in the migration section rather than suggesting neglect.

The repository has a `CHANGELOG.md`, `CONTRIBUTING.md` through the `.github/` directory, an `ISSUE_TEMPLATE.md` and a `PULL_REQUEST_TEMPLATE.md`. A CI badge points at a workflow file, and Javadoc badges point at javadoc.io for the published `io.appium:java-client` artifact, so API documentation is generated rather than written.

Three checks are worth doing before you wire this into a suite. First, find your row in the compatibility table and confirm the Selenium version you currently resolve matches one of the listed versions, then pin it. Second, confirm your Appium server major is 3 or later if you intend to move to client v11, since the two are coupled. Third, read the v10 to v11 migration guide before upgrading rather than after, because the `selenium-api` change means an explicit Selenium dependency is part of the upgrade and the OpenRewrite recipe is there to do the import work.

Editorial conclusion

The Appium java-client fits a team writing mobile or cross-platform UI tests in Java that wants W3C WebDriver semantics with driver-specific classes rather than raw HTTP calls. Do not adopt it without reading the compatibility table, because client and Selenium compatibility must be checked. Verify first which Appium server major version you run, since a client major guarantees only the current and previous server major, and pin the Selenium version explicitly rather than inheriting an open range.

Frequently asked questions

Official sources

1. appium/java-client on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases