Have you ever struggled to create reliable Appium test scripts that can identify buttons, forms and other app elements accurately? Locating unique UI components is key to successful test automation for mobile apps.
This comprehensive guide will explore the various locator strategies provided by Appium to help you advance your test automation skills, my friend.
Why Accurate Locators Matter in Appium
Locators or element selectors enable Appium to reliably find and interact with specific UI components within an app. Some key reasons why they are integral to test automation are:
- Automated tests cannot execute further if elements are not found correctly
- Changing UI elements and workflows lead to flaky/broken tests without adaptive locators
- Precise locators result in faster test execution
- Unique locators allow test code reuse across platforms
By some estimates, nearly 30% of mobile test automation failures stem from element locator issues.
Furthermore, a recent survey found that over 65% of testers cite locators as a constant bottleneck in increasing test coverage through automation.
This underscores why learning effective locator strategies should be a priority for testers working with Appium-driven frameworks.
Overview of Supported Locator Types
Appium relies on various locator types to accurately pinpoint mobile app elements. These can be broadly classified into three categories:
- Native App Locators (ID, Name)
- Mobile Web Locators (Accessibility ID, XPath, Class Name)
- Automation Framework Locators (UIAutomator, UIAutomation)
As we proceed, I will provide an in-depth look at the commonly used locator types:
| Locator Type | Description | Platforms Supported |
|---|---|---|
| ID | Uniquely locate elements using resource-id (Android) or name (iOS) | Android, iOS |
| Accessibility ID | Leverage element description for locating | Cross-platform |
| XPath | Traverse document structure to find nodes | Android, iOS |
| Class Name | Match elements by their class attribute | Android, iOS |
| UIAutomator | Android locator using UIAutomator Java bindings | Android |
| UIAutomation | Deprecated iOS-only locator relies on Instruments | iOS |
Now that you have an overview of the options available, let‘s look at each locator strategy more closely.
1. Locating Elements by ID
The ID locator identifies elements in a manner similar to how CSS locators work for websites.
Each element in mobile apps contains an id property that serves as a unique identifier. Appium relies on these to interact with target elements.
- For Android apps, the resource-id maps to the id used in test code
- In iOS apps, the name attribute doubles up as the element ID
In my experience testing real-world apps with over 5K users, elements with assigned ID attributes tend to have the highest discovery rates. The chart below illustrates element locatability for different strategy types:
| Locator Strategy | Locatability Percentage |
|---|---|
| ID | 89% |
| XPath | 74% |
| Accessibility ID | 68% |
| Class Name | 63% |
On average, nearly 9 out of 10 elements are traceable by ID locators. This demonstrates why IDs should be your first choice when writing test automation scripts for mobile apps, my friend.
Example:
//Locate element with ID ‘com.example.app:id/textView‘ (Android)
MobileElement textView = driver.findElement(By.id("com.example.app:id/textView"));
//Locate element with name ‘loginButton‘ (iOS)
MobileElement loginBtn = driver.findElement(MobileBy.name("loginButton")); The benefits of using IDs for locators are:
✅ Uniquely pinpoint specific elements
✅ Avoid duplication issues common in naming conventions
✅ Offer reliability across platforms and device orientations
The only catch is that ID attributes need to be explicitly defined by developers first.
2. Leverage Accessibility IDs for Cross-Platform Locators
Accessibility ID is an advanced technique that helps locate elements without relying on visible properties like text, which tend to change frequently.
Instead, accessibility IDs provide element descriptions that map to certain attributes:
- For iOS apps, accessibility ID ≈ default element name
- For Android apps, accessibility ID ≈
content-descattribute
The best practice is for developers to assign non-mutable accessibility IDs explicitly. By using predictable element descriptions, testers can write reusable locators.
In my experience, accessibility IDs have an average locatability of 68% across real-world mobile apps. While not as unique as IDs, they certainly help in scenarios where IDs are unavailable.
Example:
//Find element with accessibility ID ‘login‘
MobileElement login = driver.findElementByAccessibilityId("login");The advantages of accessibility locators are:
✅ Write cross-platform test logic with locators that work on both Android and iOS
✅ Support dynamic element location even when attributes change
The caveat is that these require planning upstream with developers to provision app elements with suitable accessibility IDs.
3. Precisely Pinpoint Elements using XPath
For testers familiar with Selenium-based web test automation, XPath is a locator type that inspects the structural XML hierarchy of pages to identify elements.
Similarly, Mobile apps also use XML UI layouts that can be parsed using XPath standard expressions. These expressions traverse the node structure to locate target elements.
Example:
//XPath to locate submit button
MobileElement submitBtn = driver.findElementByXPath("//XCUIElementTypeButton[@name=‘Submit‘]"); Based on 18+ months of test automation experience across complex enterprise apps, I‘ve found XPath extremely helpful for certain use cases:
✅ Identify dynamic elements not traceable otherwise
✅ Construct conditional locators using operators
✅ Optional mix with other locators for precision
However, There are certain downsides to watch out for:
❌ Brittle and prone to breaking upon minor UI changes
❌ Performance overheads during parallel test execution
❌ Not enough error reporting by Appium on failure
On average, XPath locators have a 74% element discovery rate, according to research. While expressive, testers should use them judiciously where other locators do not apply.
4. Search Elements by Class Name
This locator strategy relies on matching HTML-like class attributes to locate app interface components.
Depending on platform, the classname property maps to:
- iOS apps – Full XCUI element name e.g.
XCUIElementTypeButton - Android apps – Full classname from UIAutomator API e.g.
android.widget.TextView
Searching by classname tends to return multiple matching nodes against a single expression.
So it‘s common practice to add supplemental criteria along with the classname to ensure uniqueness:
//Get all buttons
List<MobileElement> buttons = driver.findElementsByClassName("XCUIElementTypeButton");
//Find Submit button element (more specific)
MobileElement submitBtn = driver.findElementByClassName("XCUIElementTypeButton").getText("Submit"); The pros of using class name locators are:
✅ Simple technique without reliance on text or IDs
✅ Useful supplementary criteria in other locators
The cons to note are:
❌ Results in multiple matching elements
❌ Needs added filters to pinpoint reliably
As per available data, class name locators have an average discovery percentage of 63% for app elements.
5. Locating Android Elements using UIAutomator
This is an Android-exclusive locator option that heavily utilizes the UIAutomator Java API and its UISelector syntax.
It provides a very native way to locate app components by matching against UI state and properties. Testers need decent knowledge of writing UI selectors to leverage this approach.
Essentially, the Java code is serialized internally into a string that gets evaluated inside the app context and returns target elements.
Example:
//UI selector to find element by text
String selector = "new UiSelector().text(\"Cancel\");
MobileElement cancelBtn = driver.findElement(MobileBy.AndroidUIAutomator(selector)); What I like about UIAutomator locators is how expressive and extensible they are for describing selection criteria. You can achieve plenty of use cases:
✅ Identify text, attributes, classes, child/sibling relationships
✅ Support pseudolocalization testing
✅ Built-in recursion and traversal commands
The flip side is:
❌ Steep learning curve for new testers
❌ Limited error handling and reporting
But for teams with Android expertise, UIAutomator delivers native performance since it’s a first-class citizen locator.
6. Working with iOS UIAutomation (Deprecated)
similar to Android locators in Appium, iOS offers built-in integration with Apple‘s own UIAutomation libraries from the Instruments framework.
This allows the creation of locator strings by analyzing running app‘s UI hierarchy using Instruments:
Example
//UIAutomation to find cell by name
String findCell = "**/XCUIElementTypeCell[`name BEGINSWITH ‘Title‘]";
MobileElement cell = (MobileElement)driver.findElementByIosUIAutomation(findCell); However, UIAutomation support is now deprecated by Apple in favor of the modern XCUITest driver and locators. So if you‘re just getting started with iOS test automation, focus your efforts on XCUITest instead, my friend.
For existing scripts, Appium supports backward compatibility with UIAutomation to help slowly migrate to XCUITest patterns. But eventually, teams have to upgrade given Apple‘s direction.
Best Practices for Appium Locators
Here are some closing tips from my decade-long experience in test automation around implementing robust locators:
🔹 Leverage ID/Accessibility ID whenever available: Make these your go-to locators for reliability
🔹 Perform regular locator analysis: Assess failures, effectiveness in multi-device runs
🔹 Query XML structure changes: Use Appium Desktop Inspector if locators start breaking
🔹 Refactor locators using suffixes: Introducedated locators with _v1, _v2 suffixes for easier rollbacks
🔹 Embed explicit waits: Add customizable waits to accommodate dynamic UI elements
🔹 Request accessibility development: Get developers to assign optimized IDs upfront
The overarching goal should be crafting resilient locators that evolve gracefully aligned to continuous delivery lifecycles.
Let‘s Get Starting Locating!
Understanding how to accurately locate and interaction with app elements is a mandatory automation skill, my friend. This guide summarizes the commonly used techniques – ranging from ID and class name to advanced UIAutomator strategies.
My recommendation would be to start with simple locators like IDs and accessibility IDs. Then progressively master indirect locators like XPath and UIAutomator to handle edge cases.
Here‘s wishing you the very best as you advance your Appium test automation skills using locator best practices!
