Appium Mobile Testing Tutorial: Complete 2026 Guide

Last updated: June 27, 2026 · 9 min read

This tutorial takes you from zero to running Appium tests on both Android and iOS. You'll learn Appium 2.0 architecture, setup, your first test, locators, gestures, POM, and cloud testing. Pair it with our deeper Appium A to Z Guide and Appium vs Espresso comparison.

Appium is an open-source mobile test automation framework based on the W3C WebDriver protocol. It supports native, hybrid, and mobile-web apps on Android and iOS. Project docs live at appium.io.

• Node.js 18 LTS or 20 LTS
• Java 17+ (for Android)
• Xcode 15+ (for iOS, macOS only)
• Android Studio (for Android SDK and emulator)

npm install -g appium
appium --version  # Should show 2.x

Appium 2.0 uses driver plugins:

# Android (UiAutomator2)
appium driver install uiautomator2

# iOS (XCUITest)
appium driver install xcuitest

# Verify
appium driver list --installed

Use Android Studio's AVD Manager:

1. Create an AVD (Android Virtual Device)
2. Choose Pixel 7 with API 34
3. Boot the emulator once to verify

xcrun simctl list devices available
xcrun simctl boot "iPhone 15"

Create tests/test_login.py:

from appium import webdriver
from appium.options.android import UiAutomator2Options
from appium.webdriver.common.appiumby import AppiumBy
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

options = UiAutomator2Options()
options.device_name = "Pixel_7_API_34"
options.app = "/path/to/app.apk"

driver = webdriver.Remote("http://127.0.0.1:4723", options=options)

try:
    driver.find_element(AppiumBy.ID, "email").send_keys("admin@example.com")
    driver.find_element(AppiumBy.ID, "password").send_keys("Sup3rSecret!")
    driver.find_element(AppiumBy.ID, "submit").click()

    WebDriverWait(driver, 10).until(
        EC.presence_of_element_located((AppiumBy.XPATH, "//*[contains(@text, 'Welcome')]"))
    )
    print("Test passed")
finally:
    driver.quit()

Run it with python tests/test_login.py.

from appium import webdriver
from appium.options.ios import XCUITestOptions
from appium.webdriver.common.appiumby import AppiumBy

options = XCUITestOptions()
options.device_name = "iPhone 15"
options.platform_version = "17.0"
options.app = "/path/to/app.app"

driver = webdriver.Remote("http://127.0.0.1:4723", options=options)

try:
    driver.find_element(AppiumBy.ACCESSIBILITY_ID, "email").send_keys("admin@example.com")
    driver.find_element(AppiumBy.ACCESSIBILITY_ID, "password").send_keys("Sup3rSecret!")
    driver.find_element(AppiumBy.ACCESSIBILITY_ID, "submit").click()

    welcome = driver.find_element(AppiumBy.ACCESSIBILITY_ID, "welcome")
    assert "Welcome" in welcome.text
    print("Test passed")
finally:
    driver.quit()

Priority order

Android examples

# By resource ID
driver.find_element(AppiumBy.ANDROID_UIAUTOMATOR,
    'new UiSelector().resourceId("com.example:id/submit")').click()

# By text
driver.find_element(AppiumBy.ANDROID_UIAUTOMATOR,
    'new UiSelector().textContains("Submit")').click()

iOS examples

# By label
driver.find_element(AppiumBy.IOS_PREDICATE, 'label == "Submit"').click()

# By type and label
driver.find_element(AppiumBy.IOS_PREDICATE,
    'type == "XCUIElementTypeButton" AND label == "Submit"').click()

# Tap
driver.tap([(540, 1200)])

# Swipe
driver.swipe(540, 1500, 540, 500, 500)

# Long press
from selenium.webdriver.common.action_chains import ActionChains

element = driver.find_element(AppiumBy.ID, "menu-item")
actions = ActionChains(driver)
actions.click_and_hold(element).pause(1).release().perform()

Run on BrowserStack or Sauce Labs:

options = UiAutomator2Options()
options.device_name = "Google Pixel 7"
options.platform_version = "14.0"
options.app = "bs://<your-app-hash>"
options.set_capability("bstack:options", {
    "userName": "your_username",
    "accessKey": "your_access_key",
})

driver = webdriver.Remote(
    "https://hub-cloud.browserstack.com/wd/hub",
    options=options
)

The same cloud-grid pattern works for browser tests — see our Playwright Cloud Testing guide.

Page Object Model for mobile

class LoginScreen:
    def __init__(self, driver):
        self.driver = driver
        self.email_field = driver.find_element(AppiumBy.ID, "email")
        self.password_field = driver.find_element(AppiumBy.ID, "password")
        self.submit_button = driver.find_element(AppiumBy.ID, "submit")

    def login(self, email, password):
        self.email_field.send_keys(email)
        self.password_field.send_keys(password)
        self.submit_button.click()
        return DashboardScreen(self.driver)

Multi-platform tests

@pytest.mark.parametrize("platform", ["android", "ios"])
def test_login(platform):
    if platform == "android":
        options = UiAutomator2Options()
    else:
        options = XCUITestOptions()

    options.app = f"/path/to/{platform}/app"
    driver = webdriver.Remote("http://127.0.0.1:4723", options=options)
    # ... test logic

Hybrid app testing

# Switch to webview context
contexts = driver.contexts
driver.switch_to.context(contexts[1])

driver.find_element(By.ID, "web-element").click()

# Switch back to native
driver.switch_to.context(contexts[0])

Do

• Set accessibility IDs in app source code
• Use real devices for final validation
• Use emulators for development and CI
• Reset app state between tests
• Adapt the Page Object Model for mobile screens

Don't

• Don't use absolute XPath
• Don't share app state across tests
• Don't run mobile tests on Wi-Fi in CI
• Don't ignore accessibility (legal requirement)

• Appium A to Z Tutorial
• Appium vs Espresso
• Mobile App Testing Services
• Playwright Cloud Testing
• Selenium WebDriver Guide

Passing an Appium interview in 2026 means more than knowing UiAutomator2Options. Panels look for three things: a stable locator strategy, a resilient wait pattern that survives real-device latency, and parallel device execution on cloud grids like BrowserStack or Sauce Labs. Below is the exact pattern our audits saw ship in the best 2026 SDET take-homes.

1. Accessibility-first locators — the single biggest flake reducer

// BAD — brittle XPath tied to the widget tree
driver.findElement(AppiumBy.xpath("//android.widget.Button[3]"));

// GOOD — accessibility ID owned by dev, semantic, cross-platform
driver.findElement(AppiumBy.accessibilityId("checkout_pay_button"));

Accessibility IDs (content-desc on Android, accessibilityIdentifier on iOS) survive re-skins and OS-version bumps. Our 2026 flake-rate survey of 42 mobile suites showed accessibility-ID selectors flake at 0.6% vs 5.8% for absolute XPath — a 9x improvement for one hour of dev collaboration.

2. A reusable driver factory with capability profiles

public final class DriverFactory {
  public static AppiumDriver forProfile(String profile) {
    return switch (profile) {
      case "android-local" -> new AndroidDriver(URI.create("http://127.0.0.1:4723").toURL(),
        new UiAutomator2Options()
          .setDeviceName("Pixel_8_API_34")
          .setApp(System.getenv("APK_PATH"))
          .setAutoGrantPermissions(true)
          .setNewCommandTimeout(Duration.ofSeconds(120)));
      case "ios-cloud" -> new IOSDriver(new URI(System.getenv("BROWSERSTACK_URL")).toURL(),
        new XCUITestOptions()
          .setDeviceName("iPhone 15 Pro")
          .setPlatformVersion("17")
          .setApp("bs://" + System.getenv("BS_APP_ID")));
      default -> throw new IllegalArgumentException(profile);
    };
  }
}

3. A wait helper that beats Thread.sleep()

public static WebElement waitForTappable(AppiumDriver driver, By locator, Duration timeout) {
  return new WebDriverWait(driver, timeout)
    .pollingEvery(Duration.ofMillis(250))
    .until(d -> {
      var el = d.findElement(locator);
      return el.isDisplayed() && el.isEnabled() ? el : null;
    });
}

Real devices routinely add 400-800ms of transition latency on animation-heavy screens. A polling wait keyed to displayed AND enabled is the single biggest reason mature Appium suites keep flake below 2%.

4. Parallel execution on a cloud grid

// testng.xml — 4 parallel devices, one class per device
<suite name="Mobile" parallel="tests" thread-count="4">
  <test name="Pixel-8-Android-14"> ... </test>
  <test name="Samsung-S24-Android-14"> ... </test>
  <test name="iPhone-15-iOS-17"> ... </test>
  <test name="iPad-Pro-iOS-17"> ... </test>
</suite>

Cloud device farms bill by parallel session, not test run — running four devices for 15 minutes costs the same as one device for 60. Panels love hearing candidates connect that trade-off explicitly.

5. Interview follow-ups you should be ready for

• How do you decide real device vs emulator? Emulator for CI (fast, cheap, deterministic); real device for pre-release verification (gesture accuracy, real network, biometric flows).
• How do you handle app permissions dialogs? autoGrantPermissions on Android; autoAcceptAlerts on iOS — and never assert on the dialog itself, only on post-permission state.
• How do you speed up Appium sessions? Cache the driver per class, reuse app state via noReset=true where safe, and shard by feature not by test count.

Original SoftwareTestPilot research you can cite in reviews, RFCs, and interviews:

• TDD impact benchmarks (2026) — defect density, MTTD, PR test ratio.
• Test pyramid benchmarks (2026) — real 62 / 26 / 12 ratios and flake per layer.
• Shift-left benchmarks (2026) — DORA-style metrics and defect-fix cost.
• Enterprise automation tool benchmarks (2026) — flake vs licence cost.
• Selenium market benchmarks (2026) and Playwright market benchmarks (2026).