This is the list of main changes between major versions 10 and 11 of Appium java client. This list should help you to successfully migrate your existing automated tests codebase.

The main theme of this release is that Appium java client depends on selenium-api only. The rest of Selenium (selenium-remote-driver, selenium-http, selenium-json, selenium-os, selenium-support) is not a dependency anymore. The parts of it that the client needs are now maintained in this project, so changes in the browser oriented parts of Selenium cannot break Appium sessions anymore. See Transitive dependencies management for details.

The minimum supported Appium server version is now Appium 3, and the deprecated APIs that were kept for the older servers are removed.

For Appium 3 and newer servers nothing changes on the wire: the requests sent to the server, the capabilities and the options classes, the driver classes and their methods, and the exceptions thrown for server errors are the same as in v10. What you need to adapt are the imports, the few places where your code relied on Selenium classes that the client does not extend or expose anymore, and the usages of the removed deprecated APIs.

1. Update the client to 11.x and Selenium to 4.50.0 or newer. Selenium versions below 4.50.0 won't work with Appium java client 11+. Check the Compatibility Matrix for more details. Use Appium server 3 or newer and the drivers and plugins that are compatible with it, see the Appium server.
2. Declare the Selenium modules your own code uses. They are not brought by the client anymore: selenium-support (WebDriverWait, ExpectedConditions, Select, EventFiringDecorator, ...), selenium-remote-driver (RemoteWebDriver, Augmenter, ...), browser drivers (ChromeOptions, ...).
3. Run the OpenRewrite recipe, it fixes most of the imports.
4. Fix what is left of the compilation errors using the tables below.
5. If you need RemoteWebDriver or Selenium BiDi modules, add the optional io.appium:java-client-selenium-bridge artifact, see Selenium interoperability.

The recipe file is a declarative OpenRewrite recipe. Run it before changing the client version, while the v10 types are still on the classpath. Save the file as rewrite.yml in the root of your project and run:

Maven

mvn -U org.openrewrite.maven:rewrite-maven-plugin:run \
  -Drewrite.activeRecipes=io.appium.java_client.MigrateToV11

Gradle

plugins {
    id 'org.openrewrite.rewrite' version '7.39.0'
}

rewrite {
    activeRecipe('io.appium.java_client.MigrateToV11')
}

./gradlew rewriteRun

Several recipes can be activated at once, separated with commas. The recipe does not touch your build files and does not rewrite casts to RemoteWebDriver. Review the result before committing it. If the same codebase also automates browsers, check the changes of RemoteWebElement, as the recipe replaces every usage of it.

These types are covered by the recipe. The names stay the same, only the package changes.

• The minimum supported Appium server version is Appium 3. Only the drivers and plugins that are compatible with Appium 3 or newer are supported.
• A major release of the client guarantees support only for the Appium server API of the major server version that is current at the time of the release and of the previous major version. Endpoints and commands that were removed or deprecated in the server earlier may not be supported anymore. Check the Appium 2 to 3 migration guide for the endpoints that Appium 3 removed.

The driver interfaces (InteractsWithApps, LocksDevice, PullsFiles, PushesFiles, HidesKeyboard, HasClipboard, PressesKey, StartsActivity, ...) used to call the legacy command when the server did not have the mobile: extension. They call the mobile: extensions only now, so driver.installApp(...), driver.lockDevice() and the other API methods need no change, but UnsupportedCommandException and InvalidArgumentException of the server are not swallowed anymore. If your code sends the legacy commands with MobileCommand, switch to the extensions. The arguments of the extensions differ from the ones of the legacy commands, check the documentation of the drivers.

setPowerAC requested mobile: powerAC, which the driver does not register (it is mobile: powerAc), so it always used the legacy command. It requests the right extension now.

WindowsDriver#launchApp and WindowsDriver#closeApp send windows: launchApp and windows: closeApp. The Windows driver has no extensions to transfer files, so WindowsDriver keeps sending the driver commands for pullFile, pullFolder and pushFile.

• AppiumDriver extends io.appium.java_client.remote.AppiumRemoteWebDriver, and the elements it returns are io.appium.java_client.remote.AppiumWebElement. Both implement WebDriver and WebElement from selenium-api, so code that is typed against the interfaces does not need any change.
• AppiumCommandExecutor does not extend HttpCommandExecutor anymore. Its constructors accept AppiumCommandInfo maps, and AppiumDriverLocalService instead of DriverService.
• AppiumW3CHttpCommandCodec does not extend the Selenium W3C codec anymore, and ErrorCodesMobile extends io.appium.java_client.remote.ErrorCodes.

• Custom HTTP clients and filters must implement the new HttpClient, Filter and HttpHandler interfaces, which have the same shape as the Selenium ones. The default implementation is based on java.net.http, as before. The Selenium client implementations (Netty, OkHttp) do not plug in anymore.
• AppiumClientConfig does not extend the Selenium ClientConfig anymore. The instances are immutable, and the methods that change a setting return a new instance, as before.
• AppiumClientConfig#withFilter keeps the Appium user agent and idempotency filters, and the WebSocket timeout is not reset to the default anymore when other settings are changed.
• AppiumClientConfig.directConnect, the default timeouts and the default HTTP version are not changed.

• AppiumDriverLocalService#close stops the server.
• A server that fails to start now always throws AppiumServerHasNotBeenStartedLocallyException.

• The page factory and FluentWait engine is now io.appium.java_client.support. Page objects that use the Selenium @FindBy, @FindBys, @FindAll and @CacheLookup annotations keep working if selenium-support is available, but it is recommended to switch to the annotations from io.appium.java_client.support. See Page objects.

The deprecated touch actions API is removed. A tap with W3C Actions:

var finger = new PointerInput(PointerInput.Kind.TOUCH, "finger");
var tap = new Sequence(finger, 0)
        .addAction(finger.createPointerMove(Duration.ZERO, PointerInput.Origin.viewport(), x, y))
        .addAction(finger.createPointerDown(PointerInput.MouseButton.LEFT.asArg()))
        .addAction(finger.createPointerUp(PointerInput.MouseButton.LEFT.asArg()));
driver.perform(List.of(tap));

The gestures can also be performed with the commands of the Appium drivers, for example driver.executeScript("mobile: clickGesture", Map.of("x", x, "y", y)) for UiAutomator2 and driver.executeScript("mobile: tap", Map.of("x", x, "y", y)) for XCUITest. See the driver documentation for the full list of the gesture commands.

• AppiumDriver does not implement HasBiDi anymore and the getBiDi and maybeGetBiDi methods are removed. Selenium deprecated them for removal and changed the BiDi API in an incompatible way in the recent releases.
• To use the Selenium BiDi modules (for example LogInspector), add the io.appium:java-client-selenium-bridge artifact and wrap the driver with SeleniumBridge.asRemoteWebDriver(driver). See Selenium interoperability.

• The runtime classpath of the client is selenium-api, Gson, ByteBuddy, SLF4J API and JSpecify. Guava, OpenTelemetry, selenium-manager, selenium-remote-driver, selenium-http, selenium-json and selenium-os are not brought transitively anymore. Declare the ones your code uses.
• Pinning Selenium: only selenium-api has to be pinned, see Transitive dependencies management.