Notifications
Clear all
Topic starter
06/09/2026 9:34 am
TL;DR: Modern mobile frameworks can make test automation brittle when UI hierarchies and identifiers change across builds, even if the app behaves correctly, according to Arxan Technologies. The practical lesson is that stable testable identifiers, accessibility-first design, and UI inspection are now part of mobile engineering governance, not just QA convenience.
NHIMG editorial — based on content published by Arxan Technologies: Appium and Modern Mobile Frameworks: Understanding Automation Challenges
Questions worth separating out
Q: How should teams design mobile apps so automation stays reliable across builds?
A: Teams should expose stable, explicit identifiers for key controls and avoid depending on implicit UI hierarchy or generated element names.
Q: Why do modern UI frameworks make Appium tests more brittle?
A: Modern frameworks can generate native views dynamically and alter the UI hierarchy as layouts, optimisations, or rendering states change.
Q: How can security and IAM teams think about unstable automation signals?
A: They should see them as a governance problem, not just a tooling issue.
Practitioner guidance
- Standardise stable accessibility identifiers Require every critical mobile control to expose a fixed accessibility identifier that does not change across releases, layouts, or framework optimisations.
- Validate locator stability across builds Run the same automation suite against multiple build variants and compare failures to identify identifiers that depend on internal component hierarchy or dynamic rendering.
- Inspect the UI hierarchy before scaling tests Use Appium Inspector, Xcode Accessibility Inspector, Android UIAutomator Viewer, or Android Studio Layout Inspector to verify how the app actually exposes elements to automation.
What's in the full article
Arxan Technologies' full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step examples of how Appium maps to Android and iOS native automation layers.
- Concrete locator choices, including when accessibility IDs are more reliable than XPath.
- Practical inspection workflows using Appium Inspector and platform-specific hierarchy tools.
- Developer patterns for exposing stable identifiers in React Native, Flutter, and Jetpack Compose.
👉 Read Arxan Technologies' analysis of Appium challenges in modern mobile frameworks →
Stable UI identifiers in mobile apps: what QA teams need now?
Explore further
06/09/2026 9:34 am
Stable identifiers are a governance control, not just a QA convenience. The article shows that automation reliability depends on whether the application exposes persistent, intentional identifiers rather than ephemeral UI structure. That is the same principle identity programmes apply to service accounts, workload identity, and access entitlements. When the observable signal is not stable, downstream control decisions become unreliable, so practitioners should treat identifier design as part of control governance.
A question worth separating out:
Q: What should teams do when accessibility and automation requirements conflict?
A: They should resolve the conflict by designing a single set of stable, meaningful identifiers that supports both accessibility and testing. That usually means avoiding locator strategies built on layout details and instead using explicit metadata on important elements. If one identifier can serve users and test tools, governance becomes simpler and more durable.
👉 Read our full editorial: Mobile automation fails when UI identifiers are unstable across builds
