## TL;DR

App updates change accessibility IDs and hierarchies. Switch to stable accessibility IDs owned by the app team, use resilient locator strategies, and version your locators with the app.

## Error

```text
selenium.common.exceptions.NoSuchElementException: An element could not be located using accessibility id "login_btn"
```

## Steps

1. Inspect the new app hierarchy with Appium Inspector. Expected: you see what changed.
2. Prefer `accessibility id` locators; ask the app team to keep them stable across releases. Expected: a contract.
3. Avoid XPath on mobile; it is slow and brittle. Use id, accessibility id, or predicates. Expected: faster, stabler finds.
4. Add explicit waits for elements that appear after transitions. Expected: timing handled.
5. Version-gate locators if you test multiple app versions. Expected: old and new locators coexist.

## When to use

- Locators break after an app update.
- Maintaining a mobile suite across releases.

## When not to use

- First-time locator authoring.
- Web contexts (use web strategies).

## Tool compatibility

- Appium 2.x; UiAutomator2, XCUITest drivers.

## Variant phrasings

### Appium element not found after update

The symptom; stable IDs are the fix.

### Mobile locator best practices

The general topic; accessibility IDs first.

## Why it happens

Mobile UIs change with every release and generated hierarchies shift. Locators tied to structure break; semantic IDs survive.

## Edge cases

- iOS and Android need different locator strategies; abstract per platform.
- Accessibility IDs are also the accessibility feature; two wins for one attribute.
- Hybrid apps need context switching to the webview.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_kHUH7MVar9j6nCzK4WLQPQ