Appium Interview Questions

Appium interviews test two things: whether you understand the client-server-driver chain well enough to debug it, and whether you have tested on real hardware. At the time of writing Appium 3.9 is the stable release (3.0 shipped in August 2025), and Appium 4.0 betas are being published on npm. Examples use the Appium Java client 11.

Junior level#

Explain Appium's architecture.#

Appium is a Node.js server that implements the W3C WebDriver protocol. Your test (any WebDriver client) sends commands to the server; the server hands them to a driver for the platform, and the driver talks to the platform's native automation framework:

Since Appium 2, drivers and plugins are installed separately from the server:

npm install -g appium
appium driver install uiautomator2
appium driver install xcuitest
appium plugin install images
appium

• Follow-up: "What did Appium 2 change for test code?" Non-standard capabilities need the appium: prefix, appium:automationName is mandatory, and only the W3C protocol is accepted. TestingBot's article on Appium 2 migration lists the rest.
• Red flag: "Appium is Selenium for phones." It reuses the WebDriver protocol and client libraries, but the server, drivers and capabilities are entirely its own.

What changed in Appium 3?#

Little for most test code, which is the point: it removes what Appium 2 deprecated. The minimum is Node.js 20.19 and npm 10; old endpoints and parameters are removed (for example desiredCapabilities in the new-session request, and GET /sessions, replaced by GET /appium/sessions behind the session_discovery feature flag); and insecure feature flags must be scoped to a driver:

appium --allow-insecure=uiautomator2:adb_shell

Which locator strategies do you use, in what order?#

1. Accessibility ID (content-desc on Android, accessibilityIdentifier on iOS): fast and cross-platform if developers set it.
2. ID (Android resource-id).
3. Native platform queries: -android uiautomator, -ios predicate string, -ios class chain.
4. XPath as a last resort.

driver.findElement(AppiumBy.accessibilityId("login-button")).click();
driver.findElement(AppiumBy.iOSNsPredicateString("label == 'Continue' AND visible == 1"));
driver.findElement(AppiumBy.androidUIAutomator(
    "new UiScrollable(new UiSelector().scrollable(true))" +
    ".scrollIntoView(new UiSelector().text(\"Settings\"))"));

• Follow-up: "Why is XPath slow on mobile?" The driver has to serialise the whole UI hierarchy into XML and evaluate the expression against it. On a long, complex screen that can take seconds per lookup.

Mid level#

How do you perform gestures?#

The legacy TouchAction API is gone (removed in Java client 11). Use W3C Actions, or a driver's extension commands, which are shorter and more reliable for common gestures:

// Android (UiAutomator2)
driver.executeScript("mobile: swipeGesture", Map.of(
    "elementId", ((RemoteWebElement) list).getId(),
    "direction", "up",
    "percent", 0.75));

// iOS (XCUITest)
driver.executeScript("mobile: swipe", Map.of("direction", "up"));

• Follow-up: "When would you still use W3C Actions?" For gestures no extension command covers, such as a multi-finger pattern or a precise drag path.

How do you test a hybrid app?#

List the contexts and switch into the WebView, after which normal web locators work:

Set<String> contexts = driver.getContextHandles(); // NATIVE_APP, WEBVIEW_com.example
driver.context("WEBVIEW_com.example");
driver.findElement(By.cssSelector("#promo-code")).sendKeys("SPRING");
driver.context("NATIVE_APP");

• Follow-up: "The WEBVIEW context doesn't appear." On Android, the app must enable WebView debugging in its debug build; on iOS, the web view must be inspectable.

UiAutomator2 or Espresso driver?#

UiAutomator2 is black-box: it works with any APK and can interact with system UI (notifications, permission dialogs, other apps). The Espresso driver runs inside the app's process, so it synchronises with the UI thread and is often faster and less flaky, but it needs the app to be rebuilt with the instrumentation and cannot leave the app. Native Espresso and XCUITest tests are different again; see Appium vs Espresso and Appium vs XCUITest.

Senior level#

Real devices or emulators and simulators?#

Both, for different jobs. Emulators and simulators are cheap, fast to reset and fine for functional checks on every commit. Real devices catch what virtual ones cannot: actual CPU, memory and thermal limits, manufacturer Android skins, camera and sensors, push notification delivery, real network conditions, and touch latency. An iOS simulator also runs on the Mac's architecture, so performance numbers from it mean little.

• Strong answer: "Emulators on every pull request, a real-device matrix of the models our analytics show users actually have, nightly and before release."
• Red flag: "Emulators are the same as devices."

What do you need to run Appium tests in parallel?#

Each session needs a unique device and unique ports: appium:udid plus appium:systemPort for UiAutomator2, and appium:udid plus appium:wdaLocalPort (and a unique appium:derivedDataPath) for XCUITest. Real iOS devices also need WebDriverAgent signed with a valid provisioning profile. Then your runner provides the parallelism, exactly as in web testing.

A device cloud takes this work off your hands. On TestingBot, for example, you upload the app once, reference it as appium:app with a tb:// ID, pick the device with the standard platform and device-name capabilities, and the grid allocates the device for each session; the Appium Java guide has a complete example.

A test is green on emulators and fails on one real Samsung model. Walk me through it.#

Get the Appium server log, device logcat and the video from the failing run. Common causes: a manufacturer dialog (battery optimisation, keyboard picker) covering the app, a different default keyboard changing sendKeys behaviour, slower devices exposing missing waits, or a screen size that pushes the element below the fold. Fix the test or report the product bug; do not exclude the device to make the run green.