---
title: Appium Interview Questions | TestingBot
description: '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…'
source_url:
  html: https://testingbot.com/resources/courses/selenium-interview-questions/appium-interview-questions
  md: https://testingbot.com/resources/courses/selenium-interview-questions/appium-interview-questions.md
---

Course

[Selenium & Playwright Interview Questions](https://testingbot.com/resources/courses/selenium-interview-questions)

Chapter 5 of 8

1. [1 Selenium Interview Questions](https://testingbot.com/resources/courses/selenium-interview-questions)
2. [2 Advanced Selenium Interview Questions](https://testingbot.com/resources/courses/selenium-interview-questions/advanced-selenium-interview-questions)
3. [3 Playwright Interview Questions](https://testingbot.com/resources/courses/selenium-interview-questions/playwright-interview-questions)
4. [4 Cypress Interview Questions](https://testingbot.com/resources/courses/selenium-interview-questions/cypress-interview-questions)
5. [5 Appium Interview Questions](https://testingbot.com/resources/courses/selenium-interview-questions/appium-interview-questions)
6. [6 TestNG Interview Questions](https://testingbot.com/resources/courses/selenium-interview-questions/testng-interview-questions)
7. [7 Scenario and Coding Questions](https://testingbot.com/resources/courses/selenium-interview-questions/scenario-and-coding-questions)
8. [8 Knowledge check](https://testingbot.com/resources/courses/selenium-interview-questions/knowledge-check)

[Exit course](https://testingbot.com/resources/courses)

 Chapter 5 of 8 Intermediate 5 min read Updated Nov 2026 

# Appium Interview Questions
On this page
1. [Junior level](https://testingbot.com#junior-level)
2. [Mid level](https://testingbot.com#mid-level)
3. [Senior level](https://testingbot.com#senior-level)

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[#](https://testingbot.com#junior-level)

### Explain Appium's architecture.[#](https://testingbot.com#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:

| Driver (`automationName`) | Platform | Uses |
| --- | --- | --- |
| UiAutomator2 | Android | Google's UiAutomator via a server APK on the device |
| Espresso | Android | Espresso, inside the app's process |
| XCUITest | iOS, iPadOS, tvOS | Apple's XCTest via WebDriverAgent |

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

```bash
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](https://testingbot.com/resources/articles/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?[#](https://testingbot.com#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:

```bash
appium --allow-insecure=uiautomator2:adb_shell
```

### Which locator strategies do you use, in what order?[#](https://testingbot.com#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.

```java
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[#](https://testingbot.com#mid-level)

### How do you perform gestures?[#](https://testingbot.com#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:

```java
// 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?[#](https://testingbot.com#how-do-you-test-a-hybrid-app)

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

```java
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?[#](https://testingbot.com#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](https://testingbot.com/appium-vs-espresso) and [Appium vs XCUITest](https://testingbot.com/appium-vs-xcuitest).

## Senior level[#](https://testingbot.com#senior-level)

### Real devices or emulators and simulators?[#](https://testingbot.com#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?[#](https://testingbot.com#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](https://testingbot.com/support/app-automate/appium/java) has a complete example.

### A test is green on emulators and fails on one real Samsung model. Walk me through it.[#](https://testingbot.com#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.

[Previous · Chapter 4 Cypress Interview Questions](https://testingbot.com/resources/courses/selenium-interview-questions/cypress-interview-questions) [Next · Chapter 6 TestNG Interview Questions](https://testingbot.com/resources/courses/selenium-interview-questions/testng-interview-questions)

On this page

1. [Junior level](https://testingbot.com#junior-level)
2. [Mid level](https://testingbot.com#mid-level)
3. [Senior level](https://testingbot.com#senior-level)