DEV Community: Mikhail Yesipchuk

XPath to Android UiSelector: can Claude 5.5 replace a converter?

Mikhail Yesipchuk — Sat, 24 Oct 2026 13:15:55 +0000

TL;DR

UiSelector is faster than XPath on Android: it won all 30 benchmark cases. It saved 49 % per lookup at 100 elements and 12 % at 2000 (emulator). Below level 70 of the tree, XPath finds nothing at all.
73 % of 1645 real XPath locators convert to a UiSelector. Every converted one ran on an emulator with 0 wrong results; the rest are skipped with a reason. Strict by default; --loose gives simpler, case-insensitive forms.
Claude 5.5 without rules: 47–63 wrong UiSelectors out of 680 (7–9 %). They look right and often pass a quick check. 65 of the 170 are textContains, which ignores case: wrong by a strict definition, and open to debate. With a rules prompt, Opus and Sonnet made 1 and Haiku 4, and still no model beat the converter.

npx xpath-to-uiselector ./tests          # preview the diff
npx xpath-to-uiselector ./tests --write  # apply it

Or paste your XPaths into the online converter.

Contents

Why leave XPath on Android
What a UiSelector is
Why converting by hand goes wrong
What the converter does
How I checked it
Claude 5.5 against the converter
- Is textContains really wrong?
Android is harder than iOS
The future of UiSelector
What I would use
Limits

This is the Android follow-up to my iOS posts. In part 1 I built a converter from XPath to iOS class chain; in part 2 I asked Claude to do the same job. On iOS the best model came within a few points of the converter.

On Android I did both in one go: I built xpath-to-uiselector, then asked Claude Opus, Sonnet and Haiku 5.5 to convert the same locators. Android turned out to be much harder for the models, and the reason is in the API, not in the models.

Why leave XPath on Android

With the Appium UiAutomator2 driver, an XPath lookup first serializes the whole UI tree to XML and then runs the query on it. A UiSelector (the -android uiautomator strategy) walks the live tree and, for findElement, stops at the first match. I measured both in a separate benchmark: 30 cases (10 XPath shapes × 3 targets), each found by both strategies, on screens of 100 to 2000 elements.

UiSelector won all 30 cases at every size. The saving in milliseconds grows with the tree (22 ms → 133 ms), the saving in percent shrinks (49 % → 12 %).
The depth limit matters more than the speed. The driver's snapshotMaxDepth is 70: below that, XPath and the page source see nothing. On a chain 100 levels deep, XPath found its last marker at level 66, and UiSelector found every marker down to level 100.
It is not 10–50× faster. Blog posts often say that, without showing a measurement. I measured 12–49 %: worth having on big screens and in long suites, but not a miracle.

What a UiSelector is

UiSelector is the androidx UiAutomator query builder. Appium takes it as a Java-like string and evaluates it on the device:

XPath	UiSelector
`//android.widget.Button`	`new UiSelector().className("android.widget.Button")`
`//*[@text="Pay"]`	`new UiSelector().text("Pay")`
`//*[@content-desc="Cart"]`	`new UiSelector().description("Cart")`
`//*[@resource-id="com.app:id/ok"]`	`new UiSelector().resourceId("com.app:id/ok")`
`//*[@checked="true"]`	`new UiSelector().checked(true)`
`(//android.widget.EditText)[2]`	`new UiSelector().className("android.widget.EditText").instance(1)`

It has no direct-child or parent step and no position among siblings: childSelector means any descendant, and fromParent searches among the siblings.

Why converting by hand goes wrong

The simple rows above are what everyone converts correctly. The trouble is the methods whose names promise the same thing as XPath but behave differently. All of these were checked on the emulator:

contains(@text,"Total") → textContains("Total") textContains and textStartsWith ignore case: this also finds "TOTAL". Exact: textMatches("(?s).*Total.*").
matches(@resource-id,".*\.ok") → resourceIdMatches(".*\\.ok") (in the locator text) The server's string literal unescapes only \", so the regex gets \\., a literal backslash. It matches nothing.
(//ScrollView//ImageView)[3] → …childSelector(…ImageView.instance(2)) Inside childSelector, instance() counts per container, not across the screen.
//* → classNameMatches(".*") With classNameMatches, findElements iterates index(i) and loses elements. Exact: new UiSelector().
//ListView/TextView → …childSelector(…) That is any descendant. UiSelector has no direct child, so there is no exact form.
ends-with(@text,"USD") → "skip: XPath 2.0" The driver runs XPath 2.0 unless enforceXPath1 is set: matches(), ends-with(), lower-case() all work.

The server accepts all of these: no syntax error, just other elements (or none). The first one is debatable (more on that below), but it changes what the locator finds without anyone noticing: the test passes today and taps another element when someone adds a "TOTAL" label above it.

What the converter does

xpath-to-uiselector scans your test files (Java, Kotlin, Python, JS/TS, C#, Ruby, JSON, YAML), finds the XPath strings and rewrites each one together with its strategy call:

- AppiumBy.xpath("(//android.widget.TextView[@content-desc='price'])[2]")
+ AppiumBy.androidUIAutomator("new UiSelector().className(\"android.widget.TextView\").description(\"price\").instance(1)")

- (AppiumBy.XPATH, '//*[@content-desc="Cart" and contains(@text, "USD")]')
+ (AppiumBy.ANDROID_UIAUTOMATOR, 'new UiSelector().description("Cart").textMatches("(?s).*USD.*")')

[skip] UiSelector has no direct-child criterion: //android.widget.ListView/android.widget.TextView[1]

Every XPath ends up in one of three groups:

Exact: the UiSelector finds the same elements in the same order.
Close: the same first element, but not always the same list, for example //A//B → childSelector. It comes with a warning, and --exact leaves these alone.
Skip: there is no exact UiSelector. Most skips come with a hint on how to rewrite the locator by hand.

The default is strict: a converted locator finds the same elements as your XPath, so contains(@text,"Total") becomes the case-sensitive textMatches("(?s).*Total.*"). If you prefer simpler, more tolerant locators, --loose writes textContains / textStartsWith (they ignore case) and turns a direct child //A/B into childSelector. Each loose form is marked close with a warning. On the real locators, --loose converts 77 % instead of 73 %.

The bare command only previews. --write saves, --json writes a report with every skip and warning. Node.js 20+, no dependencies. To try a single XPath without installing anything, use the online converter: it runs the same code in the browser.

How I checked it

The order was facts first, the converter last:

The source code: the UiAutomator2 server, androidx UiSelector and the XPath engine the driver uses, at pinned versions. That is where the case-insensitive Contains and the \"-only unescaping came from.
170 edge cases (6 of them for --loose), each with a hand-written expected answer, ran on an Android emulator before the converter existed: XPath and UiSelector side by side, comparing the elements they find. Where the device disagreed with me, the case was corrected.
1645 real XPath locators from 20 open-source Appium projects. Every converted one (1169 distinct XPaths) ran on random screens built from its own values and on screens built to break each condition. 0 wrong.
Checking the check: 1718 deliberately wrong UiSelectors; the screens caught 99.5 % of them.

Android 16 emulator (and Android 17 for the edge cases), Appium 3.8.0, UiAutomator2 driver 8.7.0, default driver settings. The result: 73 % convert (64 % exact, 9 % close). Most of the rest have no exact UiSelector at all: direct children, absolute /hierarchy/… paths, sibling positions, web and iOS attributes.

Claude 5.5 against the converter

I used the same setup as in the iOS comparison:

680 XPaths: 149 edge cases and 531 real locators from 19 projects, shuffled, with neutral ids.
One request per run: "convert each one to a UiSelector, or skip it with a reason". Claude Code CLI in an empty folder, Read and Write tools only, effort medium, one run per model.
The judge: every answer that differs from the converter's ran on the emulator next to the XPath.

Scoring: a correct UiSelector earns 1 point, a close one 0.5, a skip 0, and a wrong one −1 (on iOS a wrong chain scored 0): it is worse than a skip, because it looks like a valid locator and finds another element. S is the score on the edge cases, R on the real-world locators, each out of 100 over the locators that have a UiSelector at all: 104 of 149 edge cases and 387 of 531 real ones. The converter scores S 94.2 / R 96.5, not 100, because for some locators it has only a close form, worth half a point. No model beat it on any locator.

Run	Correct	Close	Wrong	Skip	Missed	S	R	Min	Cost
Converter	452	39	0	189	–	94.2	96.5	< 0.1	free
Opus 5.5	400	32	47	179	22	56.7	80.1	12.2	$3.00
Sonnet 5.5	401	32	60	176	11	43.8	80.5	4.9	$0.95
Haiku 5.5	390	32	63	169	26	37.0	78.7	5.2	$0.12

"Missed" means the model skipped a locator that the converter converts correctly. Cost is the API list price the CLI reports.

On real locators the three models are close to each other (R 79–80), but 16 points below the converter, and each still wrote 31–32 wrong answers there.
Edge cases tell the models apart: S 37 to 57 against 94.2.
7–9 % of all answers were wrong, and they look exactly like the correct ones.
Opus thought longest and was still wrong 47 times. Most of its 22 missed locators came from assuming that the driver runs XPath 1.0.

What the models get wrong

More than a third of all wrong answers are one pattern: textContains for contains(). Every model wrote it 20–23 times. The next group is a regex without (?s), where . stops at a line break; real resource ids have no line breaks, so those are mostly harmless. Then come the Java-style \\ (Sonnet alone: 15), values that exist only in the page source (an empty text, a toast, a slider's value), and positions inside childSelector.

Mistakes per model

Mistake	Opus	Sonnet	Haiku
Case-insensitive `textContains` / `descriptionContains` / `textStartsWith`	20	23	22
Missing `(?s)` in a regex	14	8	16
Java-style `\\` in a regex or value	1	15	2
Values only the page source has (`@text=""`, a toast, a range widget's value)	0	9	9
Positions: `instance()` in `childSelector`, `//X[1]`	8	0	3
`classNameMatches`, `(?i)` for `translate()`, dropped existence tests, criteria UiSelector does not have	4	5	11
Wrong	47	60	63

Each wrong answer is counted once, under the first mistake it shows.

Is textContains really wrong?

By the definition of this test, yes: contains(@text,"Total") does not find "TOTAL", and textContains("Total") does. The judge screens include such traps on purpose, so every one of the 65 answers found other elements than the XPath there.

In a real app it is less clear. Many people who write contains(@text,"Total") probably never thought about case, and a case-insensitive locator survives a designer switching a label to upper case. The cost is the other side of the same thing: a migration of hundreds of locators quietly makes each one wider. Where a "TOTAL" header sits above the "Total: $5" line, findElement now returns the header. And a check that the label reads "Total" no longer catches a change to "TOTAL".

That is why the converter is strict by default and --loose is a flag you turn on knowingly. In fact, 55 of the 65 answers are character for character what the converter writes with --loose; the other 10 are edge cases where --loose keeps the strict form (substring(), matches(), text(), a value with \). So without rules, Claude converts the way --loose does, only without saying that the locator became wider. If you count textContains as acceptable, the models made at least 27, 37 and 41 wrong answers without rules instead of 47, 60 and 63. Which side are you on? Tell me in the comments.

A prompt with rules

As on iOS, most of these mistakes are about knowing the driver, not about intelligence. So I wrote them down as general rules (about 8,000 characters, rules.md, no answers for particular locators) and ran the three models again:

Run	Correct	Close	Wrong	Skip	Missed	S	R	Min	Cost
Converter	452	39	0	189	–	94.2	96.5	< 0.1	free
Opus 5.5 + rules	448	37	1	189	5	89.4	96.3	5.9	$1.84
Sonnet 5.5 + rules	448	37	1	189	5	89.4	96.3	4.1	$0.89
Haiku 5.5 + rules	443	37	4	189	7	87.5	94.7	6.3	$0.33

Wrong answers dropped from 47–63 to 1–4, S rose from 37–57 to 88–89 and R from 79–80 to 95–96. The one left for Opus and Sonnet is a line-break case: string-length(@text)=5 → textMatches("(?s).{5}"), where ICU's . takes CR LF as one character. Haiku also dropped the className three times, against an explicit rule.
Opus got cheaper and faster with the rules: half the time, 60 % of the cost, a quarter of the thinking.
This is an upper bound. The rules were written from the mistakes on the same 680 locators, and every run was done once.

What the models gave back

The comparison also tested the converter. The first Opus run found one real converter bug: contains(@text,"1.5") was marked exact, but a slider at 1.5 has that text only in the page source, so the XPath finds the slider and the UiSelector does not. It is now a close match with a warning. Across the six runs, the models also found 8 locators the converter skipped although an exact UiSelector exists (normalize-space(), string-length(), translate(), if … then … else, and a few more). I checked each one on the emulator and added all 8 to the converter. After that, no model beats the converter on any locator.

Android is harder than iOS

On iOS, the same three Claude 5.5 models with a plain request made 4–7 wrong class chains out of 676. On Android they made 47–63 out of 680, roughly ten times as many. The gap shows on the real locators too: on iOS the models were within 2 points of the converter (R 94–95 against 96.0), on Android 16 points below it (R 79–80 against 96.5). Part of that is the scoring, since a wrong chain scored 0 on iOS and a wrong UiSelector costs 1 here: at 0, the Android R would be 87–89.

The reason is the target language, not the models. Both converters are strict in the same way: a converted locator must find the same elements as the XPath. On iOS, the obvious answer is usually also the strict one. A class chain filter is an NSPredicate, and its string operators behave like XPath's: CONTAINS and BEGINSWITH are case-sensitive unless you add [c]. So [contains(@label,"Total")] becomes [`label CONTAINS "Total"`], and that is exact.

On Android, the obvious answer is often wider than the XPath. UiSelector has methods with XPath-like names and different behaviour:

textContains and textStartsWith ignore case. This one trap is 65 of the 170 wrong answers, and it has no iOS counterpart.
The string literal is not Java: the server unescapes only \", so a Java-style \\ stays two characters.
instance() inside childSelector counts per container, not across the screen.

A model that "knows" UiSelector from Java code samples has seen these methods used, but rarely with the details that make them differ from XPath. So the case-insensitive, --loose-like answers are an Android problem: on iOS the same habit would produce the exact chain. Even if textContains counts as fine, the Android models made at least 27–41 wrong answers, about four to ten times the iOS count. The iOS mistakes were mostly of other kinds: raw line breaks inside a chain and positions such as [-1].

The two runs are not identical (iOS ran at low and medium effort, Android at medium; the locators are different), so take the ratio as a direction, not a measurement.

The future of UiSelector

Google plans to deprecate and remove UiSelector from UiAutomator, and the UiAutomator2 driver warns that every -android uiautomator locator will then stop working. No date or version is set: UiAutomator 2.4.0 (July 2026) still ships it, and the driver's server bundles 2.3.0. Appium has not announced a replacement yet (appium-uiautomator2-driver#812 is open).

So converting today is a bet that UiSelector stays until Appium moves on; no date is set yet. XPath locators are not affected, and the converter only rewrites strings, so going back is a git revert. The repository has a monthly job that opens an issue when the driver changes a file the conversion rules depend on.

What I would use

The short answer: without rules, no Claude model is safe for a bulk migration; with rules, all three get close to the converter. But the rules are what building and device-checking the converter taught me. Without that work, there would be nothing to put in the prompt.

The converter first. It is free, offline, takes under a second for 680 locators, gives the same answer every time and made no wrong UiSelector.
A model only for what the converter skips, with the rules in the prompt. With the rules, Sonnet 5.5 at medium scored the same as Opus for half the cost. Most skips have no exact UiSelector at all, so expect an explanation rather than a conversion.
Never paste a model's UiSelector into a test without running it on the screen it is meant for. Without the rules, about one in twelve was wrong, and none of them looked wrong.
Pick the strictness you want. By default the converter writes exact conversions and close ones with a warning (//A//B → childSelector); --exact writes only the exact ones. --loose adds simpler, case-insensitive forms, also as close with a warning. That is roughly how Claude converts without rules (55 of its 65 textContains answers are the same as --loose), except that the converter tells you the locator became wider.

If you use Claude Code, the repository has a skill that does exactly that: it runs the converter, then reviews each skipped locator and suggests a rewrite, marked as unverified.

Limits

Emulator only. Android 16 (and 17 for part of the checks), AOSP and Google Play images on an M1 Pro. No real phone, no older Android versions, no OEM builds.
Default driver settings only. enforceXPath1, allowInvisibleElements and similar settings change the answers.
Speed was measured on one synthetic View-based app. Compose and WebView screens were not measured.
One run per model. Two runs with the same rules gave Haiku different mistakes.
The rules were fitted on the same 680 locators they are scored on.
Only Claude models. Other LLMs were not tested.

Try it

Online converter: domovou69.github.io/xpath-to-uiselector
npx xpath-to-uiselector ./tests (npm, GitHub)
The full LLM report: audit/llm/report.md
iOS counterpart: xpath-to-class-chain

Acknowledgements

Thanks to Anthropic: Claude Code helped me build the converter, the checks and the comparison, and the Claude models are also the subject of the test. All numbers come from real runs.

Mikhail Yesipchuk, SDET/Senior QA Automation Engineer. Have you moved Android locators off XPath, and what broke? Tell me on LinkedIn or open an issue on GitHub.

XPath to iOS Class Chain: can Claude 5.5 do it instead of a converter?

Mikhail Yesipchuk — Fri, 16 Oct 2026 11:30:31 +0000

TL;DR

No model beat the converter. The best Claude run reached 96.7 % of the converter's usable chains on 676 locators and was ahead of it on none.
Without rules, every model run made wrong chains (4 to 59 per run, the converter 0). A prompt with the rules brought Opus 5.5 and Sonnet 5.5 to zero.
Use the latest model at low or medium effort, with the rules. max cost up to 4.6× more than medium for a few points; older generations were slower and made more mistakes.

Contents

The test
A plain request
Does a higher effort help?
Older models
What the models get wrong
A prompt with rules
What I would use
Limits

In part 1 I built xpath-to-class-chain, a converter from Appium XPath locators to iOS class chain, and checked it on 678 locators. The obvious question: why write a converter at all, if you can paste the locators into an LLM?

So I asked Claude to do the same job and scored the answers with the same checks. This is not me against Claude: Claude Code helped me write the converter too. The real question is whether you should let a model convert every locator directly, or use a tool built once and checked on devices.

The test

The same 678 locators: 563 real ones from production test suites and 115 hand-made edge cases. 676 are compared (one is not an XPath, one duplicates another at runtime).
One request per run: the whole list in one file, shuffled, with neutral ids, so the model cannot tell real locators from edge cases. The model writes a chain or a skip with a reason for each id.
A clean environment: Claude Code CLI in an empty folder, only Read and Write tools, no settings, no web, no examples beyond one chain in the prompt.
The same judge as the converter: a WDA emulator built from WebDriverAgent's own code runs each chain and its XPath on hundreds of generated screens and compares what they find.

Scoring, as in part 1: an exact chain earns 1 point, a documented approximation 0.5, a skip or a wrong chain 0. R is the score on real locators, S on edge cases, both out of 100. The converter scores R 96.0 / S 93.6, which is the maximum for this scoring (some locators only have an approximation). I also count the converter's 579 usable chains as 100 % and measure each model against that number.

A wrong chain below is one that WDA rejects or that finds other elements. It is worse than a skip, because it looks like a valid locator: a chain that finds another element taps the wrong button, and the Appium driver reports an invalid chain as "no such element", so it looks like a flaky test, not a syntax error.

The prompt and the run details

The plain request (full text in audit/llm/prompt.md):

input.json in the current folder has 678 XPath locators from iOS UI tests (Appium, XCUITest driver). Convert each one to an iOS class chain locator (-ios class chain) that finds the same elements. If a locator cannot be expressed as a class chain that finds the same elements, skip it and give the reason.

Then the output format: one JSON entry per id, either a chain with the -ios class chain: prefix or skip with a reason.

One run per model and effort level. Cost is the API-equivalent figure the CLI reports. I actually ran everything on a Claude Pro plan (€20 a month), so its usage limits apply: that is why xhigh was skipped and Opus max could not finish. Time is wall time, with three runs sharing one account in parallel. Scripts and raw outputs: audit/llm/.

A plain request

The best effort level of each Claude 5.5 model, plain request:

Model	R	S	vs conv.	Wrong	Min	Cost
Converter	96.0	93.6	100 %	0	seconds	free
Opus 5.5 `low`	95.1	81.9	96.7 %	4	7.1	$2.04
Sonnet 5.5 `low`	94.8	68.5	95.9 %	7	5.2	$1.03
Haiku 5.5 `medium`	94.1	63.6	93.8 %	4	6.0	$0.28

"vs conv." is usable chains against the converter's 579, "Wrong" the wrong chains, "Min" the run time in minutes.

On real locators the models are close. R 94–95 against 96.0: most real locators are simple (name, label, type, contains), and every model converts them.
The gap is in edge cases. S 64–82 against 93.6: positions, string functions, nested predicates, escaping.
Every run made wrong chains. Four in 564 sounds like little, until one of them is the locator of your checkout button.

Does a higher effort help?

Claude Code has effort levels from low to max; a higher one lets the model think longer. I ran each 5.5 model at low, medium, high and max (Opus max did not finish within the usage limit).

Opus: low and medium gave identical answers; high added 1 point of S for 39 % more cost.
Sonnet: the one real step is low → medium (S 68.5 → 77.6, same cost). max added 3.6 more for 4.6× the cost and 36 minutes.
Haiku: best at medium. At low it used zero-based indexes ([0]) and made 39 wrong chains; at max it skipped a quarter of the list.

At max, 79–89 % of the output tokens were thinking that did not improve the answer. medium is enough; for Opus, low is.

Every effort level

Model and effort	R	S	Wrong chains	Time, min	Cost
Haiku `low`	91.3	51.3	39	8.6	$0.39
Haiku `medium`	94.1	63.6	4	6.0	$0.28
Haiku `high`	94.5	61.5	5	7.6	$0.36
Haiku `max`	91.6	57.1	4	13.5	$0.64
Sonnet `low`	94.8	68.5	7	5.2	$1.03
Sonnet `medium`	94.1	77.6	7	5.3	$1.05
Sonnet `high`	94.2	77.9	7	6.0	$1.14
Sonnet `max`	95.1	81.2	6	36.0	$4.85
Opus `low`	95.1	81.9	4	7.1	$2.04
Opus `medium`	95.1	81.9	4	8.5	$2.33
Opus `high`	95.1	82.9	4	10.7	$2.83

xhigh was not run. Opus max hit the Pro plan's 5-hour usage limit twice (81 minutes and about $13 in total) without a usable result.

Older models

The same plain request to the previous generations, one run each:

Model	R	S	vs conv.	Wrong	Min	Cost
Converter	96.0	93.6	100 %	0	—	free
Opus 5.5 `low`	95.1	81.9	96.7 %	4	7.1	$2.04
Opus 5 `low`	94.5	62.5	94.5 %	6	11.6	$3.11
Opus 4.6 `low`	93.9	51.5	91.7 %	11	47.1	$5.75
Sonnet 5.5 `low`	94.8	68.5	95.9 %	7	5.2	$1.03
Sonnet 5 `low`	95.2	56.5	94.5 %	12	21.8	$2.27
Sonnet 4.6 `low` ¹	89.1	48.9	86.5 %	39	23.1	$2.58
Haiku 5.5 `medium`	94.1	63.6	93.8 %	4	6.0	$0.28
Haiku 4.5 `medium` ²	59.6	18.1	53.7 %	59	6.0	$0.61

¹ In seven runs of 100 locators: the full list wrote nothing in 20 minutes.
² In all three runs it wrote a Python converter instead of converting; this is the only run that ran its script and returned every answer.

Each new generation scored higher on edge cases, made fewer wrong chains, and was faster and cheaper. Opus 4.6 took 47 minutes and $5.75 to do worse than Haiku 5.5 did in 6 minutes for $0.28.

What the models get wrong

The wrong chains are not random. The same five mistakes come back from run to run:

Mistake	Why it is wrong	Where
A line break inside a literal written as a raw line break	WDA cannot parse the chain	10 of 11 runs, every Sonnet and Opus
`(//Button)[last()]` → `**/XCUIElementTypeButton[-1]`	WDA counts chain matches breadth-first, XPath top to bottom: another element	3–5 per run, more in stronger models
`[@label!="a"]` → [`label != "a"`]	an element without a label passes in NSPredicate and fails in XPath	Haiku, Sonnet `low`–`high`
`[.//*[@name="x"]]` → `[$name == "x"$]`	$…$ also matches the element itself, not only its descendants	Sonnet `medium`–`max`, every Opus run
`[1]` → `[0]`	class chain indexes start at 1	Haiku `low`

The models also skip things they could convert: with the plain request, Opus at every level refused matches(), ends-with() and lower-case() as "XPath 2.0 functions". WDA registers them as XPath extensions, so they are valid locators on the driver.

The other direction exists too. In the first runs, some model found an exact chain for 30 locators that the converter at that time skipped or only approximated (unions as one OR predicate, not(), quotes and backticks inside literals, string functions). I added those forms to the converter after checking them with the emulator and, where they depend on how XCTest evaluates a predicate, on a simulator and an iPhone. So the LLM runs made the converter better, and after that no model was ahead of it on any locator.

A prompt with rules

Most of the mistakes above are about knowing WDA, not about intelligence. So I wrote them down as general rules (structure, escaping, attributes, positions, what to skip) and ran the same three 5.5 runs again with them. The rules: audit/llm/prompt-v4.md, about 90 lines; there are no answers for particular locators in it.

Model	R	S	vs conv.	Wrong	Min	Cost
Converter	96.0	93.6	100 %	0	—	free
Opus 5.5 `low`	95.1	81.9	96.7 %	4	7.1	$2.04
+ rules	95.0	86.9 (+5.0)	96.7 %	0 (−4)	5.1	$1.72
Sonnet 5.5 `low`	94.8	68.5	95.9 %	7	5.2	$1.03
+ rules	95.0	84.7 (+16.2)	96.4 %	0 (−7)	8.9	$1.58
Haiku 5.5 `medium`	94.1	63.6	93.8 %	4	6.0	$0.28
+ rules	94.8	72.0 (+8.4)	95.7 %	5 (+1)	5.7	$0.27

Upper value: the plain request; lower: the same model with the rules, and the change in brackets. Column names as in the first table.

R barely moved. On real locators the models were already as good as they get.
S went up by 5 (Opus), 16 (Sonnet) and 8 (Haiku), and the three models came closer to each other.
Why Opus stays at 96.7 % of the converter. The rules fixed 12 locators: 3 of its 4 wrong chains and 9 skips of things WDA supports (matches(), ends-with(), lower-case(), @x, @index, XCUIElementTypeAny). But the model also got more careful and skipped 12 others: 7 have no exact chain, so skipping them is right, and 5 the converter does convert (self::, a union of two types, a partial type name, an absolute path with indexes, an index inside parentheses). 12 in, 12 out; the 4th wrong chain became a correct skip.
Opus and Sonnet made no wrong chains. Haiku still made two kinds of mistake (one of them four times), so it needs a check.
Still no model is ahead of the converter on any locator. With one run per model, differences of about 3 points in S are noise.

How the rules prompt was built

It took three versions, each changing one rule. The first version had no wrong chains but skipped 76 convertible real locators because of one over-cautious rule about @type; narrowing that rule fixed it. The third fixed contains(@enabled,"false"), which has to become enabled == false (CONTAINS on a boolean raises an error on the device). The rules come from what the converter's own checks found (the emulator, a simulator and an iPhone), not from guesses.

What I would use

The converter first. It is free, offline, takes seconds, gives the same answer every time and made no wrong chain. Nothing a model did was better.
A model only for what the converter skips, and only the latest generation: Opus 5.5 or Sonnet 5.5 at low or medium, with the rules in the prompt. Haiku 5.5 is six times cheaper, but even with the rules it made wrong chains. Most skips have no exact chain at all, so expect the model to explain why rather than to convert.
Check every chain a model writes on its screen (or with the harness) before it replaces the XPath.
Do not pay for max. It costs several times more, takes up to six times longer and gave at most a few points of S.

If you use Claude Code, the repository has a skill that does exactly this: it runs the converter, then explains each skipped locator and suggests a chain only where the rules give one, marked as unverified.

Limits

One run per model and effort level. Run-to-run variation was measured only in passing: about 3 points of S.
Only Claude models. Other LLMs were not tested.
The judge is the WDA emulator. The converter's chains were checked on a simulator and an iPhone; the forms only the models wrote (MATCHES, [c], $…$ with ancestor::) mostly were not.
The edge cases are deliberately unusual. On a typical test suite the gap between a model and the converter is the R column: about 1 point.
The whole list went in one request. Smaller batches may behave differently (Sonnet 4.6 only worked that way).

Acknowledgements

Thanks to Anthropic: Claude Code helped me build the test setup and analyze the results, and the Claude models are also the subject of this test. All numbers come from real runs.

Mikhail Yesipchuk, SDET/Senior QA Automation Engineer. Which model do you use for test code, and where does it go wrong? Tell me on LinkedIn or open an issue on GitHub.

XPath to iOS Class Chain: a converter you can trust, and when it is actually faster

Mikhail Yesipchuk — Thu, 15 Oct 2026 16:29:42 +0000

Converted 678 Appium XPath locators to iOS Class Chain, checked every result, and timed the two on a simulator and an iPhone. Here is what changed.

TL;DR

Class chain is ~25 % faster than XPath for a typical iOS lookup: 70 ms saved at 100 elements, 676 ms at 2000 (iPhone).
It only matters on big screens. On small ones the gain is milliseconds, and on a real project the whole test run was not faster.
~87 % of real XPath locators can be converted. The converter does it with no wrong chains and skips or flags the rest.

npx xpath-to-class-chain ./tests          # preview the diff
npx xpath-to-class-chain ./tests --write  # apply it

Contents

What a class chain is
Why converting by hand goes wrong
What the tool does
How I checked that it is right
How much faster is it?
Where the chain is slower
What I took away
Limits
Try it

If you run Appium tests on iOS, you have probably heard that XPath is slow and that -ios class chain is faster. I wanted two things I could not find anywhere:

A tool that converts existing XPath locators to class chain without silently changing which element they find.
A real number: how much faster is it, and does that depend on the size of the screen?

This post covers both. The tool is open source: xpath-to-class-chain on GitHub and npm. In short: the chain was faster in all 240 timed lookups (22–29 %, simulator and iPhone), 489 of 563 real locators have a class chain, and a few shapes (visible, lookups of dozens of elements) get slower, see below.

What a class chain is

A class chain is WebDriverAgent's (WDA's) own locator language for iOS. Like XPath, it is a path of element types. Unlike XPath, each filter is an NSPredicate in backticks:

XPath	Class chain
`//XCUIElementTypeButton` (any depth)	`**/XCUIElementTypeButton`
`//XCUIElementTypeCell/XCUIElementTypeButton` (direct child)	`**/XCUIElementTypeCell/XCUIElementTypeButton`
`[@name="Pay"]`	[`name == "Pay"`]
`[contains(@label,"Total")]`	[`label CONTAINS "Total"`]
`[@name="a" and @label="b"]`	[`name == "a" AND label == "b"`]
`//*` (any type)	`*/`

In a test, it is just another locator strategy:

// WebdriverIO
await $('-ios class chain:**/XCUIElementTypeButton[`name == "Pay"`]').click();

// Java client
driver.findElement(AppiumBy.iOSClassChain("**/XCUIElementTypeButton[`name == \"Pay\"`]")).click();

Why it is faster. For XPath, WDA takes a snapshot of the whole accessibility tree, writes it out as XML, runs the XPath over it with libxml2 and maps the matches back to elements. A class chain skips the XML step: WDA turns it straight into XCTest queries. Both still walk the whole tree, so the gain is a percentage, not a fixed number of milliseconds.

Why converting by hand goes wrong

The two languages look alike but behave differently:

Positions. XPath //Button[2] is the 2nd Button under each parent; class chain **/Button[2] is the 2nd of all matches.
Order. XPath (//Button)[2] counts matches top to bottom; WDA counts them level by level (breadth-first). No class chain counts like XPath here.
Text. == compares exactly, but CONTAINS, MATCHES and [c] compare normalized text (a fullwidth Ｑ equals Q).
Errors. The Appium driver turns an invalid chain into "no such element", so a typo looks like a flaky test, not a syntax error.

That last point is the reason for the whole project: a wrong chain does not fail loudly.

What the tool does

It scans a folder (JS/TS, Java, Kotlin, Python, Ruby, C#, PHP, JSON…), converts the XPath locators it finds and prints a diff; --write saves the files. It validates every chain, skips what has no exact class chain (with a reason), warns on approximations, and leaves alone strings passed to an explicit XPath strategy like AppiumBy.xpath("…").

A preview on four shapes that are common in real test code:

- //XCUIElementTypeStaticText[@name="Order total"]
+ -ios class chain:**/XCUIElementTypeStaticText[`name == "Order total"`]

- //*[contains(@type,"XCUIElementTypeButton") and contains(@label,"Add to cart")]
+ -ios class chain:**/XCUIElementTypeButton[`label CONTAINS "Add to cart"`]

- (//XCUIElementTypeButton[@name="product.addToCart"])[2]
+ -ios class chain:**/XCUIElementTypeButton[`name == "product.addToCart"`][2]
! grouped position: WDA counts class chain matches breadth-first, XPath in document order,
  so the element can differ when matches sit at different depths

[skip] skipped_unsupported_logic: //*[@name="Total:"]/following-sibling::*[1]

The first two are exact, the third is the closest chain there is (check it on its screen), and the fourth stays XPath: a class chain has no sibling axis.

How I checked that it is right

Every verdict comes from running the XPath and the chain and comparing what they find:

A WDA emulator. WDA's own class chain and XPath code (v16.14.1), compiled to run on a Mac. It tests each locator on hundreds of generated screens in seconds.
678 locators: 563 real ones from production test suites (anonymized) and 115 hand-made edge cases.
Real devices. 246 cases on an iOS 27 simulator and an iPhone 13 Pro Max under Appium 3.8.0 and WDA 16.14.1. Where a device disagreed with the emulator, the device won. That is how the breadth-first order was found.

Scoring: an exact chain earns 1 point, an approximation 0.5, a skipped or wrong one 0. Locators that have no class chain at all are not counted; skipping them is the right answer.

Result	Value
R, real locators	96.0 of 100
S, edge cases	93.6 of 100
Wrong chains	0

Why not 100? 39 real locators, all positions like (//Button)[2], have only an approximation, worth 0.5. So 96.0 and 93.6 are the maximum this scoring allows, and the converter reaches it.

How R and S are calculated

R = 100 × Σ points / N    N = 489 real locators that have a class chain
  = 100 × (450 + 39 × 0.5) / 489 = 96.0

S is the same score on the 83 edge cases that have a class chain, split into 9 groups (positions, string functions, escaping, logic…) and weighted by how much each group matters in real test code. Every case, group and weight is in speccases.js.

Each locator with its chain and verdict is in coverage-cases.json; the full method is in the report.

How much faster is it?

On small screens (36–275 elements) the chain was about 20 % faster, but that is only 30–65 ms. So I measured what happens as the screen grows.

Setup: a synthetic Checkout page grown to 100, 500, 1000 and 2000 elements; the 10 most common locator shapes from real tests; targets at the top, at depth 39 and at the end of the page. Each lookup is one cold findElement, median of three passes.

Elements	Simulator, ms	Saved	iPhone, ms	Saved
~100	115 → 90	21.9 %	295 → 225	23.8 %
~500	453 → 344	24.1 %	760 → 582	23.4 %
~1000	912 → 677	25.8 %	1400 → 997	28.9 %
~2000	1750 → 1310	25.4 %	2720 → 2040	24.9 %

Each cell: XPath → class chain, time per lookup.

The saving in percent does not depend on the screen size. The saving in milliseconds grows with it, because both strategies process the whole tree on every lookup.
The locator shape and the target's position do not matter. A button at the top costs as much as one at depth 39.

More findings: useFirstMatch, depth limit, simulator vs iPhone

[1] and useFirstMatch do not help. An explicit [1] takes the same code path in WDA 16.14.1. useFirstMatch (an Appium setting that makes WDA stop at the first match) was 2.7 % faster at 100 elements and 5.7 % slower at 2000, 15 % slower for deep targets.
Nothing deeper than 50 levels is found by either strategy (WDA's default snapshotMaxDepth). The error is a plain "no such element".
A real iPhone is 1.5–2.6× slower than the simulator, mostly a fixed per-request cost over USB. The ratio between XPath and chain stays the same.

Where the chain is slower

On the small screens, four shapes were slower as a chain (simulator; the iPhone showed the same):

Locator	XPath	Chain
`//XCUIElementTypeButton[@visible='true']`, 32 matches	2.05 s	12.6 s
`//XCUIElementTypeCell[@visible="true"]/XCUIElementTypeButton`	3.46 s	5.14 s
`//XCUIElementTypeButton[@name]`, 36 matches	1.15 s	1.78 s
`/XCUIElementTypeApplication/XCUIElementTypeWindow/XCUIElementTypeButton`	0.12 s	0.75 s

visible is the main trap: WDA checks visibility for every candidate. These four cases outweighed all the gains, and over the whole small-screen run XPath was faster in total (53.7 s against 64.8 s). Without them, the chain was 3.8 % faster.

So on small screens XPath is fine. The gain shows up on big trees: long feeds and lists, screens kept alive in a navigation stack or in tabs, off-screen drawers. An iPad with several windows on screen should behave the same way (not measured).

What I took away

Faster lookups do not automatically mean faster tests. On a real project with simple screens, run on Sauce Labs devices (iOS 16, 18, 26), the timed lookups got faster, but the total run time barely changed: a few milliseconds are lost next to app launch, network and waits.

My rule of thumb: convert for speed where the screens are big, and convert lookups of one element by name, label, value or type. Check visible predicates, list lookups and absolute paths first.

Limits

Only lookups were measured in a controlled way, not whole tests. With implicit waits or retries, a missed lookup repeats the whole search, so the saving multiplies by the number of attempts.
The big screen is synthetic; no production app was benchmarked.
One WDA version (16.14.1). Its class chain lookup changed recently (appium/WebDriverAgent PR #1194), so other versions may give other numbers.
One phone and one Mac (M1 Pro). Absolute times will differ on yours; the ratio should not.

Try it

It is on npm; you need Node.js 20 or newer, nothing else. Start with the screens that have the most elements: dump the page source of your heaviest screen and count them.

npx xpath-to-class-chain ./tests          # preview
npx xpath-to-class-chain ./tests --write  # save
npx xpath-to-class-chain ./tests --json   # report with every skip and warning

Then review the warnings, run your suite, and check each grouped position and visible locator on its screen. Everything behind the numbers in this post (the audit, the emulator, the device app) is in audit/; its README says where to start.

Next: can an LLM do this instead?

In part 2 I give the same 678 locators to Claude models (Opus, Sonnet and Haiku, several generations, every effort level) and score them with the same checks. Short version: no model beat the converter on real locators, and a prompt with the rules mattered more than the model or the effort level.

Acknowledgements

Thanks to Anthropic: Claude Code helped me build the converter, the test harness and the device benchmark, and analyze the results. All numbers come from real runs.

Mikhail Yesipchuk, SDET/Senior QA Automation Engineer. If you try the converter on your suite, I'd like to hear what it skipped and why: open an issue on GitHub or message me on LinkedIn.