Automating Native, Hybrid and Mobile Web Apps with Appium
Core concepts
To automate an app you must locate elements with strategies suited to each app type. Native apps use accessibility IDs, resource IDs (Android), and XCUITest predicates/class chains (iOS). Mobile web uses standard web locators inside the browser context. Hybrid apps switch between NATIVE_APP and WEBVIEW contexts, so you must call getContextHandles() and setContext() before interacting with web content, and enable webview debugging on the device.
Learn desired capabilities: platformName, platformVersion, deviceName, app/appPackage+appActivity, automationName, browserName, noReset, and udid. Understand the session lifecycle: create session, find elements, interact, quit. Know waits-implicit vs explicit-and why explicit waits on element state are preferred over sleeps. Understand gestures via the W3C Actions API and mobile-specific commands like press, swipe, and scroll.
Traps in exam questions
- Forgetting that hybrid tests must switch context; a web locator fails in NATIVE_APP.
- Assuming
findElementreturns immediately; it throwsNoSuchElementExceptionif absent. - Confusing
noReset(keep app data) withfullReset(uninstall/reinstall). - Using
browserNamefor native apps instead ofapp. - Expecting identical locators across iOS and Android; accessibility IDs are the closest cross-platform strategy.
Rule of thumb
Match the locator to the context: native context โ accessibility/resource IDs; webview context โ CSS/XPath. Always switch context explicitly before querying.
Worked example: A hybrid app shows a native login then a webview dashboard. The test sets NATIVE_APP, logs in, calls getContextHandles(), selects the WEBVIEW_... handle, then locates the dashboard heading by CSS selector.