Appium interview questions for SDET and mobile automation roles cluster around six areas: how Appium's architecture works, capabilities, locators, gestures, hybrid apps, and how you run mobile tests in a framework and CI. Below are the questions that come up most, grouped the same way, with answers you can say out loud in under a minute. Everything reflects Appium 2 and the current Java client.

Appium Basics

1. What is Appium?

Appium is an open-source tool for automating native, hybrid and mobile-web apps on Android and iOS (and some desktop platforms) using the W3C WebDriver protocol. You write tests with a client library in Java, Python, JavaScript, C# or Ruby, and the same API drives both platforms.

2. Why do teams choose Appium?

  • One API for Android and iOS, so skills and much of the framework are shared.
  • No need to modify or recompile the app under test.
  • It speaks WebDriver, so Selenium knowledge, page objects and test runners carry over.
  • Open source with a large community and support from every major device cloud.

3. What are the limitations of Appium?

Tests are slower than native frameworks such as Espresso or XCUITest run directly, setup (SDKs, Xcode, drivers, signing) takes time, iOS automation needs a Mac, and gestures and some system dialogs need platform-specific commands. Interviewers like candidates who know these trade-offs rather than claiming Appium is perfect.

4. What is the difference between native, hybrid and mobile web apps?

A native app is built with the platform SDK (Kotlin/Java, Swift). A hybrid app wraps web content in a native shell using a WebView. A mobile web app is a website opened in the phone's browser. Appium handles all three: native through the platform driver, web content through the WEBVIEW context, and browsers through Chrome or Safari automation.

Advertisement

Architecture

5. Explain the Appium architecture.

Appium is a client-server system. Your test (the client) sends W3C WebDriver commands over HTTP to the Appium server. The server routes each command to a driver for the platform, such as UiAutomator2 for Android or XCUITest for iOS. The driver talks to the device using the vendor's own automation framework and sends the result back to the server and then the client.

6. What changed in Appium 2?

Appium 2 ships the server without any drivers. You install the drivers you need with appium driver install uiautomator2 or appium driver install xcuitest, capabilities must follow the W3C format (Appium-specific ones use the appium: prefix), and plugins can extend the server, for example for image comparison.

7. Which drivers does Appium use for Android and iOS?

For Android, UiAutomator2 is the standard; Espresso is faster and more stable but needs access to the app's build. For iOS, XCUITest, built on Apple's XCTest framework, is the only current option.

8. What is Appium Inspector?

A desktop app that connects to a running Appium session and shows the screen, the element tree and each element's attributes. You use it to find locators and test them before putting them into code, much like DevTools for web.

Capabilities and Sessions

9. What are capabilities in Appium?

Key-value settings sent when a session starts that tell Appium what to automate and how. Common ones are platformName, appium:automationName, appium:deviceName, appium:app (path or URL of the app), appium:appPackage and appium:appActivity for an installed Android app, appium:bundleId for iOS, and appium:noReset.

10. How do you start an Android session in Java?

UiAutomator2Options options = new UiAutomator2Options()
    .setDeviceName("Pixel_7_API_34")
    .setApp(System.getProperty("user.dir") + "/apps/app-debug.apk")
    .setNoReset(false);

AndroidDriver driver = new AndroidDriver(
    new URL("http://127.0.0.1:4723"), options);

Java client 8 and later use typed options classes such as UiAutomator2Options and XCUITestOptions instead of DesiredCapabilities. Appium 2's default server path is the root (/), not /wd/hub.

11. What is the difference between noReset and fullReset?

noReset=true keeps the app and its data between sessions, which is faster and keeps you logged in. fullReset=true uninstalls the app and clears data after the session, giving a clean state at the cost of time. The default sits in between: app data is cleared but the app stays installed.

Locators

12. Which locator strategies does Appium support?

Accessibility ID (content-desc on Android, accessibility identifier on iOS), ID (resource-id on Android), class name, XPath, and platform-specific ones: UiAutomator selectors on Android, and iOS predicate strings and class chains on iOS.

13. Which locator should you prefer, and why avoid XPath?

Prefer accessibility ID because it works on both platforms and is stable, then resource-id. XPath on mobile is slow, because the driver has to build the whole UI hierarchy as XML for every lookup, and it breaks when the layout changes. If developers don't add accessibility IDs, ask them to; it also improves accessibility for real users.

14. How do you scroll to an element that is off-screen on Android?

driver.findElement(AppiumBy.androidUIAutomator(
    "new UiScrollable(new UiSelector().scrollable(true))" +
    ".scrollIntoView(new UiSelector().text(\"Settings\"))"));

UiScrollable scrolls until the element is visible. On iOS, use the mobile: scroll command with a direction or a predicate.

Gestures and Device Actions

15. How do you perform swipe, long-press and drag in Appium 2?

TouchAction and MultiTouchAction are deprecated. Use either W3C actions (PointerInput and Sequence), which work across platforms, or the driver's mobile: commands, such as mobile: swipeGesture, mobile: longClickGesture and mobile: dragGesture on UiAutomator2, which are shorter and more reliable.

((JavascriptExecutor) driver).executeScript("mobile: swipeGesture", Map.of(
    "left", 100, "top", 500, "width", 600, "height", 600,
    "direction", "up", "percent", 0.75));

16. How do you handle system permission pop-ups?

On Android, set appium:autoGrantPermissions to grant runtime permissions at install time, or tap the dialog's Allow button by locator. On iOS, appium:autoAcceptAlerts or autoDismissAlerts handle system alerts, or you can switch to the alert and accept it.

17. How do you hide the keyboard, rotate the device or put the app in the background?

driver.hideKeyboard(), driver.rotate(ScreenOrientation.LANDSCAPE) and driver.runAppInBackground(Duration.ofSeconds(5)). App state can be controlled with activateApp, terminateApp and queryAppState.

Hybrid Apps and Contexts

18. How do you automate the web part of a hybrid app?

Set<String> contexts = driver.getContextHandles(); // NATIVE_APP, WEBVIEW_com.example
driver.context("WEBVIEW_com.example");
driver.findElement(By.cssSelector("#email")).sendKeys("a@b.com");
driver.context("NATIVE_APP");

Inside the WEBVIEW context you use normal web locators. On Android, the app must have WebView debugging enabled in its debug build.

19. How do you test a mobile website with Appium?

Set browserName to Chrome (Android) or Safari (iOS) instead of an app capability. Appium opens the browser and you write ordinary Selenium-style tests against the page.

Framework, CI and Real Devices

20. How would you design an Appium framework for both Android and iOS?

Page objects with platform-specific locators (the @AndroidFindBy and @iOSXCUITFindBy annotations with PageFactory and AppiumFieldDecorator, or a locator map per platform), a driver factory that reads the platform from configuration, ThreadLocal drivers for parallel runs, test data and capabilities in config files, and TestNG or JUnit for execution and reporting.

21. How do you run Appium tests in parallel?

Each parallel session needs its own device and, on Android, unique appium:systemPort values (for iOS, appium:wdaLocalPort). Use a ThreadLocal driver, pass the device details from testng.xml or a device pool, and either run one Appium server with different ports per session or several servers.

22. Emulators and simulators or real devices?

Emulators and simulators are cheap and fast for everyday regression in CI. Real devices are needed for performance, battery, camera, push notifications, real network conditions and manufacturer-specific behaviour. Most teams run the bulk on emulators and a smaller real-device suite on a device cloud before release.

23. How do you run Appium tests in a CI pipeline?

Start an Android emulator in headless mode (or use a device cloud), start the Appium server, run the Maven or Gradle test command, and publish reports and screenshots in a step that runs even when tests fail. iOS jobs need macOS agents.

Scenario Questions

24. A test passes on the emulator but fails on a real device. What do you check?

Screen size and density (an element may be off-screen), OS version and manufacturer skin differences, slower performance needing better waits, permission dialogs that only appear on fresh devices, and network differences. Capture a screenshot and page source at the failure point to compare.

25. Your Appium suite is slow. How do you speed it up?

Replace XPath with accessibility IDs, use noReset and deep links to skip repeated login and navigation, set test data through APIs instead of the UI, avoid fixed sleeps, run in parallel across devices, and keep the slow full suite out of every commit.

How to Prepare

Practise answering out loud with the Appium interview simulator, and see the architecture and capabilities animated in the Appium visualizer. Because most mobile roles also test web and APIs, review the Selenium interview questions and API testing interview questions too.