Appium

Appium automates native, hybrid, and mobile-web apps on Android and iOS from a single API. It is an HTTP server written in Node.js that exposes the W3C WebDriver protocol — the same protocol Selenium speaks — so your existing WebDriver client (Java, Python, JS, C#, Ruby) drives a phone the way it drives a browser.

Client → W3C WebDriver (HTTP/JSON) → Appium server → platform driver → vendor automation framework → device/emulator. The cross-platform promise lives in one layer: your test talks to Appium, and Appium delegates to whatever the OS provides.

The key idea is delegation. Appium itself doesn't know how to tap a button on iOS — it forwards the command to Apple's own XCUITest framework. On Android it forwards to Google's UiAutomator2. Appium is the universal translator; the vendor frameworks do the real driving.

A driver is the plugin that bridges Appium to a specific platform's automation engine:

• UiAutomator2 — the default and recommended Android driver (wraps Google's UiAutomator2).
• XCUITest — the iOS driver (wraps Apple's XCUITest).
• Espresso — alternative Android driver, faster and in-process, but Android-only.
• Mac2 / Windows / Flutter — desktop and framework-specific drivers.

A test session is configured with capabilities — key/value pairs telling Appium what to automate. Vendor-specific keys carry an appium: prefix under W3C.

Order of preference favors stability and cross-platform reuse:

• accessibility id — best choice: maps to Android content-desc and iOS accessibilityIdentifier, so one locator can work on both platforms.
• id — Android resource-id; fast and stable when present.
• -android uiautomator — runs a native UiSelector query on-device (powerful, fast).
• -ios predicate string and -ios class chain — native iOS queries, far faster than XPath.
• class name — element type (android.widget.Button, XCUIElementTypeButton).
• xpath — works everywhere but is the slowest and most brittle; the whole UI tree is serialized and searched on every query.

Because Appium is WebDriver-based, the synchronization story mirrors Selenium — and is just as central to interviews.

new WebDriverWait(driver, Duration.ofSeconds(15))
    .until(ExpectedConditions.elementToBeClickable(
        AppiumBy.accessibilityId("submit")));

Taps, swipes, scrolls, and drags are core to mobile. The modern approach uses the W3C Actions API (pointer input sequences) or, more simply, driver-side mobile: commands.

• mobile: scroll, mobile: swipe, mobile: tap, mobile: longClickGesture — executed natively by the platform driver; concise and reliable.
• W3C Actions — build a PointerInput sequence (press → move → release) for custom gestures like pinch or precise drags.

A hybrid app embeds web content (a WebView) inside a native shell. Appium exposes each as a context:

• NATIVE_APP — drive native widgets via UiAutomator2/XCUITest.
• WEBVIEW_* — drive the embedded web page with Selenium-style CSS/DOM locators.

Switch with the context API:

driver.getContextHandles();          // [NATIVE_APP, WEBVIEW_com.app]
driver.context("WEBVIEW_com.app");   // now use CSS selectors
driver.context("NATIVE_APP");        // back to native

Page Object Model applies exactly as on the web — one screen object per screen, encapsulating locators and actions, so a UI change touches one file. Appium Inspector is the GUI that connects to a session, renders the live element tree, and helps you craft and verify locators.

Appium wins on cross-platform reuse and language freedom; native frameworks win on raw speed and stability. The usual recommendation: Appium for broad black-box E2E across both platforms, native frameworks when a single-platform team wants the fastest possible feedback.