In Appium, which flake sources does a mobile run have that a browser run cannot?
answer
- you are fighting the device too
- three moving parts, not one
- windows your app does not own
- the tree is a photograph
- different machinery on each platform
basics
~20 sMobile adds five failure sources a browser page cannot have: system animation moving the target, the soft keyboard drawn over it, an OS-owned prompt above the app, a slow emulator or simulator, and an element tree that is already stale.
solid answer
~40 sA browser test fights the page; an Appium test also fights the device and the OS. Five sources have no browser twin. **System animation** moves the target between the find and the tap — Android turns it off with `appium:disableWindowAnimation`, Apple platforms with the XCUITest driver's `reduceMotion` setting. **The soft keyboard** covers the target, and it is a separate window on Android that UiAutomator2's default source omits until `enableMultiWindows` is set, whereas XCUITest reports it inside the app's own element tree. **An OS-owned prompt** is drawn above the app on a schedule the test never authored. **A slow emulator or simulator** stretches every step. And **the element tree is a snapshot** — Android's read from the accessibility node tree, Apple's taken by WebDriverAgent — so it can be history before your command lands.
go deeper
Be ready to name the sources out loud: system animation, the soft keyboard, an OS-owned prompt, a slow virtual device, and an element tree that is already stale. Naming them clearly is the whole bar here.
Explain why each source exists — the agent only sees the screen through the accessibility layer, and the app is one window among several — and give the Android and the Apple mechanism for at least animation and the keyboard.
Show how you decide from evidence which source you are looking at, and why a fix written with Android's disableWindowAnimation capability does nothing on an XCUITest run against an iPhone.
Own the position that mobile-only causes are fleet configuration to be removed once, not per-suite workarounds, and that because the two platforms diverge, a single cross-platform switch is a design goal rather than a safe assumption.
## Why mobile has its own flake catalogue A browser end-to-end run has one moving part between the command and the assertion: the page. An Appium run has three — the app, the operating system drawing over it, and the phone, emulator or simulator the whole thing runs on. The extra two produce intermittent failures a browser suite structurally cannot have, and each one has a different lever on Android than it has on Apple platforms. The reason is architectural. Appium reaches the app through a device-side agent: on Android the UiAutomator2 driver pushes and starts a helper server on the device, and on Apple platforms the XCUITest driver builds, installs and launches WebDriverAgent. Everything your test learns about the screen travels through that agent, and everything the agent knows travels through the platform's accessibility layer. Anything that perturbs the screen, that layer, or the device's speed becomes a source of intermittency — and the two platforms perturb differently. ## The five sources - **System animation.** A transition, a ripple or a sheet slide keeps the target moving after it exists. The find succeeds, a rectangle is captured, and the pointer lands where the element used to be. Android exposes the class as device-wide animation scales that `appium:disableWindowAnimation` switches off for the session; Apple's equivalent is the accessibility Reduce Motion preference, reachable as the XCUITest driver's `reduceMotion` setting, with `animationCoolOffTimeout` as its settle-side companion. - **The soft keyboard.** The keyboard is drawn over the bottom of the app, so a control that exists is not reachable. The divergence is what each platform's tree tells you: on Android the input method is a *separate window*, and UiAutomator2's default source carries only the active app's window until the `enableMultiWindows` setting is on, so the obstruction is invisible in the data; XCUITest reports the keyboard inside the app's own element tree, where the `visible` and `hittable` attributes describe the occlusion. - **A prompt the OS owns.** A permission request or a system alert is drawn above your app by the platform, not by your process, and it arrives on the platform's schedule — a first run after install, an OS nag, a low-storage warning. Handling one is its own subject; what belongs here is that it is a flake source precisely because it is not in your app's control flow. - **A slow virtual device.** An emulator or simulator sharing a CI host with other work stretches every step: the app draws later, the agent answers later, and every bound that was comfortable on a workstation becomes marginal. The same suite passes on a laptop and fails in the pipeline. - **A stale element tree.** Neither driver streams the UI. Android's on-device server reads the accessibility node tree at the moment you ask; WebDriverAgent takes an XCUITest snapshot. The handle you hold describes that instant, so a screen that re-lays out between the find and the command — a greenhouse climate dashboard refreshing its sensor rows, a warning banner pushing the list down — makes your command act on a screen that no longer matches. ## What is genuinely different per platform | Source | Android, UiAutomator2 driver | Apple platforms, XCUITest driver | |---|---|---| | Motion | `appium:disableWindowAnimation` drops the device's animation scales for the session | `reduceMotion` setting; `animationCoolOffTimeout` bounds the settle | | Keyboard in the tree | a separate window, absent unless `enableMultiWindows` is set | inside the app's element tree, with `visible` and `hittable` | | Where the tree comes from | the accessibility node tree, read by the on-device server | an XCUITest snapshot taken by WebDriverAgent | | App stops answering | the on-device server is a separate process and keeps replying | `accessibilityDeadline` bounds the wait on the app's accessibility layer | ## How to use the catalogue 1. **Name the source before changing anything.** "Flaky" is not a cause. "The vent-schedule sheet was still animating" and "the keyboard covered the setpoint field" have different fixes and different owners. 2. **Ask which platform failed.** A run that only fails on one platform is usually hitting a mechanism the other does not have; the keyboard window and the tree-construction difference are the two that catch people most often. 3. **Prefer removing a source to absorbing it.** Turning motion off deletes a whole class of races; anything that only makes the race less likely leaves it in the suite. 4. **Re-find rather than reuse.** Because the tree is a snapshot, a handle carried across an app state change is a guess about a screen you have not looked at since. ## The boundary of this catalogue These are *mobile-only causes*. How long to wait, how often to poll, whether to retry a failed case and when to quarantine one are general automation subjects and are not what makes a mobile run different. What makes it different is that the device animates, draws windows the app does not own, runs slowly when it is virtual, and describes itself only in snapshots — and that Android and Apple do each of those with different machinery, which is why a fix written for one platform routinely does nothing on the other.
- Which of those five sources can you delete outright, and which can only be absorbed?Motion can be deleted: Android's `appium:disableWindowAnimation` and the XCUITest driver's `reduceMotion` take the class off the device for the session. A slow virtual device and an OS-owned prompt can only be absorbed or handled when they appear, since neither is under the test's control. Snapshot staleness is structural — you cut exposure by re-finding instead of holding handles across a state change.
- Why can a browser suite not have the keyboard and OS-prompt failure classes at all?A browser test lives inside one window the browser owns, and the page is the whole world it can see. On a device the app is one window among several: the input method is drawn by another process on Android, and permission and system alerts are drawn by the OS above every app. Those windows sit outside the app's control flow, so they interrupt on a schedule the test never authored.
saying these in an interview costs you the question
- Says mobile flake has the same causes as browser flake
- Treats the page source as a live view of the screen
- Assumes the soft keyboard appears in both platforms' element trees
- Thinks one animation switch covers Android and Apple platforms
- Blames the app when the OS drew the prompt above it