skip to content

In Appium, how is a web-view context handle named on Android compared with iOS?

level: juniorimportance: must knowfreq 66%

answer

  1. same prefix, different suffix
  2. NATIVE_APP plus one per web view
  3. Android suffix reads like a package
  4. Apple suffix is a runtime page id
  5. match on Android, discover on iOS

basics

~20 s

Both platforms share the WEBVIEW_ prefix and then diverge: Android appends the package name of the process hosting the web view, while iOS appends a numeric page id that the remote debugger assigns at runtime.

solid answer

~40 s

A context list always contains the native handle, `NATIVE_APP`, plus one handle per detected web view, and each of those begins with `WEBVIEW_`. What follows the prefix is platform-specific. On Android it is the package name of the process hosting the view, so the refill-reminder app's handle is readable, predictable, and matchable by its suffix from one run to the next. On iOS it is a numeric page id issued by the remote debugger when it attaches, so it is meaningful only inside the current session and has to be discovered rather than remembered. That one difference decides how a suite selects handles: an Android helper can match a known package, while an Apple one must list first and choose by detail, never by a value copied from a previous run.

go deeper

for a junior

Recall the shape: NATIVE_APP for native, WEBVIEW_ plus a package on Android, WEBVIEW_ plus a page id on iOS. Say both halves, not only the platform you used last.

for a middle

Explain why the Apple id is per-session while the Android suffix is not, and what that forces a test to do differently when it looks for its handle each run.

for a senior

Show how the difference shapes a real suite: matchable handles on Android, discovery on iOS, and a failure message that prints the listing when nothing matches.

for a principal

Decide how much of this divergence the framework hides and how much it exposes, so page objects stay platform-neutral without pretending the two platforms behave the same.

## The anatomy of a handle Every context an Appium session can serve has a string handle, and a hybrid session normally shows two kinds. The native surface is `NATIVE_APP` on Android and on iOS alike — one name, no variation, and the handle you post to get back to native widgets. Every detected web view is named with the `WEBVIEW_` prefix followed by something that identifies the view. That suffix is where the platforms part company, and it is the single fact this leaf exists to teach. ## Android: the suffix is a hosting package On Android the text after the prefix is the package name of the process hosting the web view. For the pharmacy refill-reminder app, whose insurance co-pay page is rendered inside the app's own process, the handle is human-readable and recognisably the app's. Two properties follow from that: - It is stable. The same build on the same screen produces the same handle, run after run, so a test may match it by suffix. - It is descriptive. When a device shows several handles, their packages already tell you which process each view belongs to before you read any further detail. One caution: the suffix names the process that hosts the view, which is not automatically the package of the app under test. A view rendered by a separate component or process can appear under a different package, so a suite that assumes its own package will always be the listed one can pick nothing at all on some devices. ## iOS: the suffix is a runtime page id On iOS the text after the prefix is a numeric page id. The remote debugger assigns it when it attaches to the page, which has three consequences worth stating plainly: - It is not stable across runs. The number you saw yesterday identifies nothing today. - It is not descriptive. A number tells you neither which application nor which page it belongs to. - It cannot be predicted or configured. There is no setting that pins it to a value your test already knows. So on iOS the handle is always discovered inside the run that uses it, and identification has to come from somewhere other than the name — typically the per-view detail that `mobile: getContexts` returns on the XCUITest driver. ## The comparison in one table | | Android (UiAutomator2 or Espresso) | Apple (XCUITest) | |---|---|---| | native handle | `NATIVE_APP` | `NATIVE_APP` | | web-view prefix | `WEBVIEW_` | `WEBVIEW_` | | what follows the prefix | the package of the hosting process | a numeric page id | | stable across runs | yes | no | | safe matching rule | suffix match on the package | discover, then match on view detail | The prefix and the native handle are shared; everything to the right of the prefix is not. An answer that names only one platform's shape has answered half the question, and in an interview that half is usually the platform the candidate happened to work on last. ## What this means for a real suite 1. List the contexts at the point of use, because the refill-reminder app's web view does not exist until the user reaches the co-pay screen. 2. Filter to handles starting with `WEBVIEW_` — never assume there is exactly one. 3. On Android, narrow by the hosting package when the app renders its own view. 4. On iOS, skip name-based narrowing entirely and choose by the view's detail instead. 5. Post the chosen handle, do the web work, then post `NATIVE_APP` to return to the native reminder screens. ## Pitfalls that come straight from the naming - Writing one hardcoded handle string into a shared helper and expecting it to work on both platforms; it can be right on at most one. - Storing an Apple page id in test data or configuration, which produces a switch failure on the very next run. - Posting the bare prefix as if it were a handle; it is a prefix, not a name, and nothing answers to it. - Assuming the Android suffix is the current activity or screen rather than a package. - Believing the native handle differs by platform and inventing a second name for it. The shape to carry away is small enough to recite: `NATIVE_APP` on both; `WEBVIEW_` plus a package on Android; `WEBVIEW_` plus a page id on iOS; match the first, discover the second.

  • Does the Android handle's package always match the app under test's own package?
    Not necessarily. The suffix names the process hosting the web view, and that can be a different package when the view is rendered by another component or process. Match the handle you actually want by its detail rather than assuming the app's own package will be the one listed, or the helper silently finds nothing on those devices.
  • How should one cross-platform helper return the right handle for both platforms?
    Give it a single job: list the contexts, filter to `WEBVIEW_` handles, then choose by the evidence each platform can supply — a package suffix on Android, a view's title or URL on iOS. Return `NATIVE_APP` explicitly when the caller wants native, and fail with the full listing in the message so a missing handle is obvious.

saying these in an interview costs you the question

  • Says both platforms use the same web-view handle string
  • Stores an Apple page id in test data and reuses it
  • Thinks the bare WEBVIEW_ prefix is a postable handle
  • Expects the Android suffix to be an activity rather than a package
  • Believes the native handle differs between Android and iOS