Appium
The cross-platform mobile automation standard — a single framework that drives native iOS and Android apps by extending the WebDriver protocol to mobile platforms.
The Hook: Mobile is Everywhere
Look around you. Most people in NZ interact with businesses through their phones, not their laptops. Whether it's checking a bank balance on the bus or buying a pie with an app, mobile is the primary screen. Appium is the king of mobile automation, allowing you to test real apps on real iPhones and Androids using the same logic.
Mastering Appium isn't just about testing; it's about becoming a specialist in the most valuable sector of the tech market.
The Rule: One API, Two OSs
The golden rule of Appium is Abstraction. You shouldn't have to write one test for Android and a completely different one for iOS. Appium uses the WebDriver protocol to hide the complexity, so your click() command works the same way whether it's hitting an Apple button or a Google one.
The Analogy: The Universal Remote
Think of Appium as a Universal Remote Control. You don't care how the TV (Android) or the Soundbar (iOS) actually processes the "Volume Up" signal. You just press the button on your remote. Appium is that remote, translating your simple commands into the complex instructions the phone hardware needs.
Senior engineer insight
The real shift in thinking about Appium comes when you stop treating it as a web testing tool bolted onto mobile and start treating the device itself as the system under test. On a recent banking super-app project I worked on, we discovered our suite was passing consistently in CI but failing on real devices in the hands of testers — the emulators didn't replicate the memory pressure of 47 other apps running in the background. Moving to a real device farm changed everything; our crash rate in production dropped 60% in the next release cycle.
The tipping point for me was realising that Appium's stability is almost entirely determined by decisions made before you write a single line of test code — device selection, capability tuning, and build pipeline design matter more than test logic.
The most common mistake: teams test exclusively on emulators/simulators, ship to production, and then wonder why their automated suite gave them a false green when real customers hit real-world failures.
From the field
A Wellington fintech building a KiwiSaver management app assumed their iOS and Android codebases were functionally identical — same feature set, same backend, one Appium suite to cover both. Six weeks into building the suite they discovered Android's biometric authentication flow returned control to the app at a completely different point in the lifecycle than iOS did, which meant the "same" test step was trying to interact with an element that didn't exist yet on one platform. The team had written 200 tests before the gap surfaced because they'd only been running against Android in CI.
The lesson that generalises: always run at least a smoke suite against both platforms from day one, even if you only have ten tests. Platform divergence compounds silently — the earlier you find it, the cheaper the fix.
The Setup: The Doctor is In
Appium setup is notoriously tricky (you need Android Studio, Xcode, and Node). The secret weapon is appium-doctor. Run it, and it will tell you exactly what's missing from your system.
npm install -g appium-doctor
appium-doctor --android
appium-doctor --iosThe First Script: Desired Capabilities
Appium needs to know *what* device to talk to. We use Capabilities (a JSON object) to define the environment.
{
"platformName": "Android",
"deviceName": "Pixel_7_Pro",
"app": "/path/to/my-nz-app.apk",
"automationName": "UiAutomator2"
}Once connected, you find elements just like on the web: driver.findElement(By.id("login_btn")).click();
The "Gotcha": Accessibility IDs
Mobile apps don't use "CSS Selectors." If you try to use XPath for everything, your tests will be slow and break every time the UI changes slightly.
The Fix: Demand Accessibility IDs from your developers. These are unique labels for elements that don't change. They make your tests 10x faster and help users with vision impairments — a double win!
The Framework: Drivers & Servers
Appium is a Client-Server architecture. Your test code is the client, and the Appium Server is the middleman. It sends your commands to "Drivers":
- UiAutomator2: The engine for Android.
- XCUITest: The engine for iOS.
Understanding this helps you debug. If the server is running but the app won't launch, the problem is usually in the Driver or the Capabilities.
The NZ Example: TradeMe App Login
Let's look at how we'd automate a login on the TradeMe app. Notice the use of AccessibilityId.
// Java + Appium
WebElement loginBtn = driver.findElement(AppiumBy.accessibilityId("log-in-tab"));
loginBtn.click();
driver.findElement(AppiumBy.accessibilityId("email-field")).sendKeys("tester@resync.nz");
driver.findElement(AppiumBy.accessibilityId("password-field")).sendKeys("KiwiTest123");
driver.findElement(AppiumBy.accessibilityId("submit-login")).click();The Pro Move: Context Switching
Many apps (like banking or news apps) are "Hybrid." They show a web page inside the native app. Seniors know how to switch "Contexts" so they can use web selectors inside a mobile test.
Set<String> contexts = driver.getContextHandles();
driver.context("WEBVIEW_com.mybank.nz"); // Now testing the web layer!The Challenge: Your Turn
Mobile devices use Gestures (swiping, pinching, long-pressing). A simple click() isn't always enough.
Your Task: Research the Sequence API in Appium. Write down the pseudo-code for a "Swipe Left" gesture on a gallery of images. What are the start and end coordinates you would use?
Why teams fail here
- XPath over-reliance: Teams default to XPath locators copied from Appium Inspector without ever asking devs to add Accessibility IDs — the tests become brittle the moment the UI is reskinned, which happens every sprint in a fast-moving NZ startup.
- Skipping appium-doctor: Engineers spend days debugging mysterious driver failures because they never ran the diagnostics tool that would have flagged the missing Android SDK platform-tools in 30 seconds.
- Ignoring hybrid context switching: Any app that renders a WebView — common in NZ government digital services and bank apps using embedded web forms — requires explicit context switching; teams that don't know this spend weeks chasing "element not found" errors that have nothing to do with the element.
- No wait strategy: Mobile network conditions and device performance are far more variable than a desktop browser — hard-coded sleeps and missing explicit waits are the single biggest source of flaky Appium suites in every project I've reviewed.
Key takeaway
Appium gives you the key to the door, but whether your mobile test suite actually opens it depends on the device strategy, locator discipline, and wait architecture you put in place before you write a single test — everything else is just syntax.