Appium
Cross-platform mobile automation for iOS and Android. Uses the WebDriver protocol — familiar if you know Selenium.
Overview
Appium is an open-source mobile automation framework that extends the WebDriver protocol to iOS and Android devices. First released in 2013, it allows teams to write one test suite that runs against both platforms using the same API they already know from Selenium. Appium 2.0 (2022) introduced a plugin architecture, improved element finding, and better performance.
For NZ teams building mobile apps — particularly in fintech, health, and e-commerce — Appium is the default choice when cross-platform coverage is required. It supports native apps, hybrid apps, and mobile web.
What it's used for
Appium is the right tool when:
- Cross-platform mobile testing: Write tests once in Java, JavaScript, Python, or C# and run them on both iOS and Android.
- Hybrid app testing: Apps built with React Native, Flutter, Ionic, or Cordova can all be tested with Appium.
- Device farm integration: Connect to BrowserStack, Sauce Labs, or AWS Device Farm for testing on hundreds of real devices.
- Existing Selenium skills: Teams already familiar with WebDriver can transition to mobile with minimal retraining.
Pros & Cons
Pros
- Same WebDriver API as Selenium — minimal learning curve for existing teams
- Supports native, hybrid, and mobile web applications
- Cross-platform: one test suite for iOS and Android
- No app modification required — tests run against the compiled app
- Strong cloud integration with BrowserStack, Sauce Labs, AWS Device Farm
Cons
- Slower than native frameworks (Espresso, XCUITest) due to WebDriver protocol overhead
- Setup is complex: requires Xcode, Android SDK, and device configuration
- Flakier than native tools, especially on older devices or slow networks
- Element locators can be fragile across OS versions
- Limited support for advanced gestures compared to native frameworks
Platforms & Integrations
Appium runs on Windows, macOS, and Linux. The Appium server must run on macOS to test iOS devices (physical or simulator). Android testing works from any OS.
Pricing
| Tier | Cost | Includes |
|---|---|---|
| Open Source | Free | Appium server, all drivers, all language bindings |
| Cloud Device Labs | $29-$500/mo | Real device access, parallel execution, test analytics |
NZ Context
NZ mobile app teams — across banking, e-commerce, and telco — frequently run Appium alongside BrowserStack or Sauce Labs for real-device coverage across iOS and Android. For teams shipping to both platforms, Appium is typically the first cross-platform framework evaluated, largely because it reuses existing Java or JavaScript test infrastructure. NZ financial services organisations and large retailers have invested heavily in Appium suites, and those suites don't get rewritten lightly. In practice, many NZ teams settle into a hybrid pattern: native frameworks (Espresso for Android, XCUITest for iOS) own the critical-path regressions, while Appium covers smoke tests and cross-platform journeys — giving Appium a durable role even as the ecosystem matures.
Alternatives
- Espresso — Google's native Android framework. Faster and more reliable, but Android-only.
- XCUITest — Apple's native iOS framework. Best for deep iOS integration, but iOS-only.
- Maestro — Simple YAML-based mobile testing. Much faster setup than Appium.
When to choose Appium
A quick decision guide for NZ teams evaluating mobile testing options.
| Choose Appium when… | Choose something else when… | Combine with… |
|---|---|---|
| Your team ships both iOS and Android and you want one test suite | You only ship Android — Espresso will be faster and less brittle | BrowserStack — real-device coverage without maintaining a physical device lab |
| Your team already has Selenium/WebDriver skills in Java, Python, or C# | You only ship iOS and need deep gesture or accessibility testing — XCUITest is the right call | Espresso or XCUITest — keep Appium for cross-platform smoke tests, native frameworks for critical-path regression |
| You need to run tests against a device farm (BrowserStack, Sauce Labs, AWS Device Farm) | Your app is brand-new and still changing rapidly — Maestro's YAML scripts are far quicker to write and rewrite | Maestro — use Maestro for exploratory and fast-feedback tests, Appium for the stable regression suite in CI |
| You're testing a React Native or Ionic hybrid app where platform-specific frameworks give incomplete coverage | Test execution time is critical and you can't afford WebDriver protocol overhead — native frameworks execute 3–5× faster | Selenium Grid — reuse your existing grid infrastructure to run Appium tests in parallel across multiple devices |
What I would do
Practitioner judgment on tool adoption, team onboarding, and when to swap.
The bottom line: Appium shines as a cross-platform regression gate in CI — not as a first-touch exploratory tool. Use Maestro or manual testing while the app is unstable, introduce Appium once core flows are locked, and always run it against real devices on a cloud farm rather than simulators.
Interview questions
Questions you are likely to get if you list Appium on your CV — with what interviewers are really testing for.
What is Appium and how does it differ from Espresso or XCUITest?
What they’re really testing: Whether you understand the trade-off between cross-platform flexibility and native performance, not just whether you can spell the tool names.
Strong answer covers: Appium uses the WebDriver protocol over HTTP, meaning it adds a layer of network overhead that native frameworks avoid; Espresso and XCUITest run in-process and execute 3–5× faster; in a NZ context where many teams ship both iOS and Android (e.g. banking apps, government portals), Appium’s single test suite is worth the speed cost for cross-platform smoke coverage.
When would you choose Appium over Maestro for a new mobile project?
What they’re really testing: Whether you make tool decisions based on project maturity and team context, not just personal preference or trend-following.
Strong answer covers: Maestro’s YAML-based flows are ideal when the app is still changing rapidly; Appium becomes the right call once core flows are stable and you need CI integration, parallel execution across a device farm (BrowserStack, Sauce Labs), and the ability to write tests in Java or Python to match what the wider NZ dev team already uses.
You’re a QA engineer at a NZ fintech company. Your Appium tests pass on your local simulator but fail intermittently on the CI pipeline. How do you diagnose and fix this?
What they’re really testing: Whether you can distinguish environment-related flakiness from genuine test or app bugs, and whether you have a systematic debugging approach rather than just retrying.
Strong answer covers: Check Appium server logs for timeout vs element-not-found errors; compare iOS simulator version locally vs CI (version mismatches cause selector drift); switch to real-device cloud (BrowserStack) to eliminate simulator inconsistencies; add explicit waits rather than implicit sleeps; for a NZ fintech context, also flag that authentication flows may behave differently under CI network conditions and should be mocked at the API layer.
Your Appium suite takes 90 minutes to run and the team is talking about dropping mobile automation. What do you do?
What they’re really testing: Whether you treat automation as a practice to optimise rather than a fixed cost, and whether you can make a business case under pressure.
Strong answer covers: Audit for test independence first (sequential tests are the most common cause of long runtimes); enable parallel execution via Appium’s parallel capabilities across Sauce Labs or AWS Device Farm; apply the 80/20 rule — identify the 20% of tests that catch the most defects and retire the rest, targeting a 20-minute gate; frame the business case in NZ terms: a 90-minute pipeline blocks multiple releases per day, which has direct revenue and Privacy Act breach-risk implications for customer-facing apps.
How would you structure an Appium test suite for a React Native app that needs to run in CI, cover both iOS and Android, and remain maintainable as the app grows?
What they’re really testing: Whether you can design for long-term maintainability, not just get tests passing today.
Strong answer covers: Use the Page Object Model to isolate element locators from test logic; store platform-specific capabilities in separate config files (not hardcoded); use accessibility IDs as locators rather than XPath (they survive OS upgrades and satisfy the NZ Web Accessibility Standard 2.1 audit trail); split iOS and Android into parallel CI pipelines; version-pin the Appium server and driver in package.json so the suite doesn’t break on a dependency upgrade between sprints.