skip to content

In Appium, what does the `class name` strategy match on Android compared with iOS?

level: middleimportance: must knowfreq 61%

answer

  1. type filter, not an identity
  2. exact match, no subclass walking
  3. one vocabulary is open, one closed
  4. dotted Java class versus XCUIElementType
  5. unclassified controls become Other

basics

~20 s

On Android the class name strategy matches a fully qualified widget class such as android.widget.Button. On iOS it matches an XCUIElementType value such as XCUIElementTypeButton. Both are exact string comparisons over two vocabularies that share nothing.

solid answer

~40 s

`class name` is declared by both native drivers and on both it means "an element whose type string equals this" — an **exact comparison**, not a subclass test. What differs is the vocabulary. On **Android**, the UiAutomator2 driver compares against the element's `class` attribute, a fully qualified Java class name such as `android.widget.EditText` or `androidx.recyclerview.widget.RecyclerView`, drawn from an open set that any library can extend. On **Apple platforms**, XCUITest compares against the element's `type`, an `XCUIElementType` value such as `XCUIElementTypeTextField` or `XCUIElementTypeCell`, drawn from a closed enumeration. No value is legal on both platforms, so a `class name` locator can never be shared. On either platform it selects a *kind* of control, not a particular one.

code

json · 4 lines
json
{
  "androidUiAutomator2": { "using": "class name", "value": "android.widget.EditText" },
  "appleXcuitest":       { "using": "class name", "value": "XCUIElementTypeTextField" }
}

go deeper

for a junior

Be ready to recognise the two shapes on sight: a dotted Java class name belongs to an Android locator, an XCUIElementType value to an Apple one. Never paste one into the other.

for a middle

Explain the exact-match semantics and the open-versus-closed vocabularies, and why an Apple class name locator is usually coarser than the Android equivalent for the same control.

for a senior

Demonstrate when class name is worth using at all — as a narrowing step in a scoped search — and how you decide it is too weak to carry a locator by itself.

for a principal

Own the durability argument: a type filter survives copy changes and breaks on layout growth, and you should be able to say which of those risks your product actually runs.

## What `class name` addresses `class name` is a locator strategy both native Appium drivers declare, and on both it carries the same shape of meaning: return elements whose type string is **equal to** the value you sent. Three properties follow on either platform, and they are the part that does travel: - It is an **exact string comparison**. The driver does not walk a type hierarchy, so asking for a base type does not return its specialisations. - It supports **no wildcards** and no partial matching of its own. - It selects a **kind** of control, never an identity, so a screen with twelve buttons has twelve matches. What does not travel is the vocabulary the string is drawn from. The Android vocabulary and the Apple vocabulary have no value in common, which means a `class name` locator is the one strategy on this leaf that cannot even *pretend* to be portable — it fails loudly rather than quietly. ## Android: fully qualified widget class names On Android the UiAutomator2 driver compares against the element's `class` attribute as reported in the page source: a dotted, fully qualified Java class name. - Typical values are `android.widget.Button`, `android.widget.TextView`, `android.widget.EditText`, `android.widget.ImageView` and `androidx.recyclerview.widget.RecyclerView`. - The set is **open**. Any library or app can contribute class names, so the vocabulary of a given screen is whatever that build happens to render. - Read the value out of the live page source rather than assuming it is the type you wrote in a layout file. The tree reports the class it reports, and that is the string the comparison uses. - Because the names are long and specific, an Android `class name` find is often narrower than the Apple equivalent — sometimes narrow enough to feel unique by accident, which is a trap of its own. ## Apple platforms: `XCUIElementType` names XCUITest compares against the element's `type` attribute, which is an **`XCUIElementType`** value: `XCUIElementTypeButton`, `XCUIElementTypeStaticText`, `XCUIElementTypeTextField`, `XCUIElementTypeSecureTextField`, `XCUIElementTypeCell`, `XCUIElementTypeSwitch`, `XCUIElementTypeOther`, and the rest of that family. - The set is **closed**: it is XCTest's own enumeration of element types, and an app cannot add to it. - Every value carries the `XCUIElementType` prefix, so an Apple `class name` locator is visually unmistakable. - Anything the accessibility layer cannot classify surfaces as `XCUIElementTypeOther`, which is usually the most populous type on the screen. - The vocabulary is deliberately coarse. It describes what a control *is for*, not what it was implemented with, so two very different views can share one type. ## The two side by side | | Android (UiAutomator2) | Apple platforms (XCUITest) | |---|---|---| | attribute matched | `class` | `type` | | vocabulary | fully qualified Java class names | `XCUIElementType` values | | open or closed | open — libraries add to it | closed — fixed by XCTest | | example value | `android.widget.EditText` | `XCUIElementTypeTextField` | | unclassifiable control | reports whatever class the tree gives it | collapses to `XCUIElementTypeOther` | | typical selectivity | narrower, sometimes accidentally unique | coarse, usually many matches | ## Why this is a filter, not an address On both platforms `class name` answers "what kind of thing is this", and interviews probe whether you know the difference between that and "which thing is this". A locator that names only a kind is stable against renames and re-copy, and unstable against anything that adds a second control of the same kind — a new button in a toolbar, an extra row in a list, a redesign that wraps content in another container. That is why `class name` earns its keep as a **narrowing step inside a scoped search** and rarely as a whole locator on its own. ## Using it without getting burned 1. **Never share the constant.** No string is valid on both platforms, so any shared `class name` value is a bug waiting for the other platform's run. 2. **Take the value from the source of the device you are targeting**, not from memory and not from the other platform's tree. 3. **Assume multiple matches** and decide deliberately what you want when there is more than one, rather than relying on the first. 4. **Expect the Apple side to be coarser.** If a locator has to distinguish two controls of the same type, `class name` alone cannot do it there. The summary a candidate should be able to give in one breath: same strategy name, same exact-match semantics, two vocabularies with zero overlap — Java widget classes on one side, `XCUIElementType` values on the other.

  • Does a `class name` find for `android.widget.TextView` on Android also return button elements?
    No. The comparison is an exact string match against the element's `class` attribute, not a subclass or `instanceof` test, so a node reporting a different class string is simply not a match. If you want several kinds of control you need several finds, or a strategy that can express alternatives.
  • Why do so many iOS elements come back as `XCUIElementTypeOther`?
    `XCUIElementType` is a closed vocabulary describing what a control is for. When the accessibility layer cannot map a view onto one of those roles — a custom-drawn container, a decorative wrapper — it lands on `XCUIElementTypeOther`. That makes `Other` the most common type on many screens and effectively useless as a locator on its own.

Android class names are surnames from an open register: anyone may coin a new one, and they get long and specific. Apple element types are a short list of job titles, and every control has to be filed under one of them however unusual it is.

saying these in an interview costs you the question

  • Says class name matches subclasses of the named type
  • Uses an XCUIElementType value in an Android locator
  • Thinks class name identifies one element rather than a kind
  • Expects the two platforms to share any class value
  • Assumes the Android class equals the type declared in the layout