A Node.js process that implements the WebDriver protocol for mobile. It receives commands from your Java client and routes them to platform drivers like UiAutomator2 or XCUITest.

A plug-in in Appium 2.x that translates generic WebDriver commands into platform-specific automation. Examples: UiAutomator2 (Android), XCUITest (iOS).

A typed Java options class for configuring Android sessions that use the UiAutomator2 driver. Replaces many legacy uses of raw DesiredCapabilities.

A typed Java options class for configuring iOS sessions that use the XCUITest driver. Holds fields like platformName, deviceName, platformVersion, and app.

Accessibility ID Locator

An element locator strategy that targets an element's accessibility identifier. Recommended for stable, cross-platform Appium tests on Android and iOS.

Apple's UI testing framework for iOS, used by Appium to automate iOS apps on simulators and real devices.

The current major version of Appium (as of 2026) where platform drivers are installed and managed as separate plug-ins from the core server.

What is UiAutomator2?

A popular Android automation framework used by Appium to drive native and hybrid Android apps.

What is Accessibility id?

A locator strategy in Appium that targets the accessibility identifier of UI elements, providing a stable, human-readable way to find elements.

Appium Fundamentals: Java + WebDriver for Mobile — Practical Mobile Test Automation in Java for Android and iOS

From Selenium to Appium: What Actually Changes?

WebDriver, Now for Mobile

Appium lets you reuse your Selenium + Java skills to drive Android and iOS apps using the WebDriver protocol. You still write WebDriver-style tests, but now they control mobile apps instead of browsers.

Appium 2.x Today

As of 2026, Appium 2.x is standard. Platform drivers like UIAutomator2 (Android) and XCUITest (iOS) are separate plug-ins that you install and manage independently from the core Appium server.

Client–Server–Driver Model

Your Java test (client) sends WebDriver commands to the Appium server. The server forwards them to a platform driver that knows how to tap, type, and swipe in Android or iOS apps.

What Feels Familiar

You still create driver instances, locate elements with id or xpath, and call methods like click() and sendKeys(). The big differences are capabilities, device setup, and mobile gestures.

Appium Architecture: Client, Server, Drivers

Your Role: The Client

Your Java test is the Appium client. It uses the Appium Java client library to send WebDriver commands to an Appium server URL, with options describing which device and app to control.

The Appium Server

The Appium server is a Node.js process listening on HTTP (e.g., port 4723). It accepts WebDriver-style JSON commands and forwards them to the correct platform driver plug-in.

Drivers as Plug-ins

In Appium 2.x, platform drivers like uiautomator2 (Android) and xcuitest (iOS) are separate plug-ins you install via the Appium CLI, not bundled in the core server.

Command Flow

A call like driver.findElement() becomes JSON from Java to the server, then to the platform driver, which talks to Android or iOS. The response travels back the same path to your test.

Desired Capabilities vs Options in Modern Java Clients

Legacy vs Modern Style

Old Appium code uses a generic DesiredCapabilities map. Modern Appium Java client versions favor typed options classes like UiAutomator2Options and XCUITestOptions instead.

Android Options Snapshot

Typical Android fields: platformName("Android"), deviceName("Android Emulator"), automationName("UiAutomator2"), plus either app(.apk path) or appPackage + appActivity.

iOS Options Snapshot

Typical iOS fields: platformName("iOS"), deviceName("iPhone 15 simulator"), platformVersion("17.0"), automationName("XCUITest"), and app(.app or .ipa path).

Why Use Options Classes?

Options classes give you autocompletion and fewer typos than raw capability maps, and they match current Appium Java client best practices in 2026.

Creating an AndroidDriver Session in Java

Here is a minimal, modern example of starting an Appium session on an Android emulator using UiAutomator2 in Java.

Creating an IOSDriver Session in Java

Now compare the Android setup with iOS using XCUITest. The pattern is the same; only the options and app format change.

Basic Interactions: Taps, Typing, Scrolling, Swipes

Clicks and Typing

Taps are usually element.click(), and typing is element.sendKeys("text"). You still locate elements by id, accessibility id, or xpath, just like in Selenium.

Locators that Age Well

For cross-platform tests, accessibility id is your friend. It maps cleanly to Android content-desc and iOS accessibilityIdentifier, making tests more stable.

Gesture Basics

Scrolls and swipes are built from press–move–release actions. You define start and end coordinates and let Appium convert them into native touch events.

Coordinate Mental Model

Picture the screen as a 100x100 grid: (50,80) is bottom center, (50,20) is top center. Swiping from (50,80) to (50,20) scrolls a list upward.

Putting It Together: First Cross-Platform Login Test

Scenario: Simple Login Flow

We will write JUnit tests that launch the app, tap a Login button, and type a username on both Android and iOS, using almost identical Java code.

Android Test Shape

AndroidLoginTest uses UiAutomator2Options in @BeforeEach to create AndroidDriver, a @Test to click login and type, and @AfterEach to quit the driver.

iOS Test Shape

IOSLoginTest mirrors the structure with XCUITestOptions and IOSDriver. The interactions remain the same, only the platform-specific options differ.

Key Takeaway

Appium lets you keep one testing style and mental model while swapping drivers and options to target Android or iOS, which is ideal for cross-platform teams.

Thought Exercise: Debugging Your First Session

Imagine you run your new Android test and immediately get a `SessionNotCreatedException`. Here are three real-world issues that often cause this in 2026 setups.

For each one, pause and think: What would you check or change first?

Appium server not reachable

Error mentions `Connection refused` or `Failed to connect to /127.0.0.1:4723`.
What would you verify on your machine?

Mismatched device name

Your options use `.setDeviceName("Android Emulator")` but your actual AVD is named `Pixel7API_34`.
How could you confirm and fix this?

Wrong app path

You set `.setApp("/Users/you/app-debug.apk")`, but the file actually lives at `/Users/you/projects/demo/app-debug.apk`.
What quick check can you do before re-running the test?

Write down a short checklist for yourself, for example:

Step 1: Ping the Appium server URL in a browser.
Step 2: List available emulators/simulators from the CLI.
Step 3: Verify the app path exists using your file explorer or `ls`.

This mini-checklist will save you time every time you start a new project.

Check Understanding: Appium Sessions and Options

Test your grasp of Appium fundamentals with a quick question.

In a modern Appium 2.x + Java setup (as of 2026), which of the following is the BEST way to configure an Android session using the UiAutomator2 driver?

Use DesiredCapabilities, set "browserName" to "Chrome", and create a generic WebDriver instance.
Use UiAutomator2Options, set platformName to "Android", deviceName, automationName to "UiAutomator2", and app or appPackage/appActivity, then create an AndroidDriver.
Skip capabilities/options entirely and let Appium auto-detect the device and app at runtime.

Show Answer

Answer: B) Use UiAutomator2Options, set platformName to "Android", deviceName, automationName to "UiAutomator2", and app or appPackage/appActivity, then create an AndroidDriver.

Option 2 matches current best practice: use the typed UiAutomator2Options class, set Android-specific fields (platformName, deviceName, automationName, and app or appPackage/appActivity), and create an AndroidDriver with the Appium server URL. Option 1 describes a browser test, and option 3 is not how Appium works.

Review Key Appium Terms

Flip these cards to reinforce the core concepts before moving on.

Appium Server: A Node.js process that implements the WebDriver protocol for mobile. It receives commands from your Java client and routes them to platform drivers like UiAutomator2 or XCUITest.
Platform Driver: A plug-in in Appium 2.x that translates generic WebDriver commands into platform-specific automation. Examples: UiAutomator2 (Android), XCUITest (iOS).
UiAutomator2Options: A typed Java options class for configuring Android sessions that use the UiAutomator2 driver. Replaces many legacy uses of raw DesiredCapabilities.
XCUITestOptions: A typed Java options class for configuring iOS sessions that use the XCUITest driver. Holds fields like platformName, deviceName, platformVersion, and app.
Accessibility ID Locator: An element locator strategy that targets an element's accessibility identifier. Recommended for stable, cross-platform Appium tests on Android and iOS.
AndroidDriver / IOSDriver: Concrete WebDriver implementations in the Appium Java client used to control Android and iOS apps respectively.

Key Terms

XCUITest: Apple's UI testing framework for iOS, used by Appium to automate iOS apps on simulators and real devices.
Appium 2.x: The current major version of Appium (as of 2026) where platform drivers are installed and managed as separate plug-ins from the core server.
UiAutomator2: A popular Android automation framework used by Appium to drive native and hybrid Android apps.
Accessibility id: A locator strategy in Appium that targets the accessibility identifier of UI elements, providing a stable, human-readable way to find elements.
Appium Java client: A Java library built on WebDriver that lets you write Appium tests in Java, providing classes like AndroidDriver, IOSDriver, UiAutomator2Options, and XCUITestOptions.
Desired capabilities: Key–value pairs that describe the desired test environment (platform, device, app). In modern Java clients, often wrapped by typed options classes rather than used directly.
Emulator / Simulator: Virtual devices used for testing: emulators for Android, simulators for iOS. They mimic real devices but run on your development machine.