In Appium, which request returns the current page source on Android, and what does iOS add?

## The request itself `GET /session/:sessionId/source` is the W3C WebDriver *Get Page Source* command, and it is one of the few commands whose spelling is identical on both mobile platforms: Appium's UiAutomator2 driver answers it on Android and the XCUITest driver answers it on Apple platforms. The response is a single XML string describing the screen as a tree of nodes with attributes. Point a session at a translation-glossary app sitting on its term list and the dump shows the search field, the source and target language pickers, and one node per glossary row it reaches, nested the way the interface nests them. The route is spelled with `:sessionId`, it carries no request body, and there is nothing to tune per call — you get whatever the driver's current snapshot bounds produce at the instant you ask. ## One request, two different trees The endpoint is shared. What it serialises is not, and that is the part interviewers are actually probing. | Aspect | Android — UiAutomator2 driver | Apple — XCUITest driver | | --- | --- | --- | | Who builds the tree | `io.appium.uiautomator2.server`, on the device | WebDriverAgent, asking XCTest for a snapshot | | What is walked | the accessibility node hierarchy the platform publishes | an `XCUIElement` snapshot of the application it treats as active | | Node names | Android widget class names, such as `android.widget.TextView` | `XCUIElementType…` names | | A second way to ask | none — the endpoint is the only source command | `mobile: source`, an execute method | | Sample shaping settings | `snapshotMaxDepth`, `allowInvisibleElements`, `enableMultiWindows` | `snapshotMaxDepth`, `snapshotMaxChildren`, `useJSONSource` | Because the producers differ, "the page source" is a per-platform artefact. An XPath written against an Android dump names Android widget classes and matches nothing in an iOS dump, which names `XCUIElementType…` values; the reverse is equally true. Treating one dump as the specification for both suites is the single most common beginner error on this endpoint. ## What `mobile: source` adds on Apple platforms The XCUITest driver declares an execute method named `source`, invoked as `mobile: source` and posted like every execute method to `POST /session/:sessionId/execute/sync`. It reaches the same underlying snapshot as the protocol endpoint, but being a driver command rather than a protocol command it can carry driver-specific options that the W3C route has no room for. Around it, XCUITest exposes settings that change what the serialisation contains at all: `useJSONSource`, `includeHittableInPageSource`, `includeNativeAccessibilityElementInPageSource` and `pageSourceExcludedAttributes` among them. The Android side has no `mobile: source`; there you shape the dump with UiAutomator2 settings such as `includeExtrasInPageSource` and `includeA11yActionsInPageSource` and then call the same endpoint. ## "Snapshot" is the load-bearing word The things a new user most often gets wrong all follow from what a snapshot is: - The dump is built **when you ask for it**. It is not a live view; a glossary row that renders a moment later is not in a dump you already hold. - It is **bounded**. Depth limits and visibility filters apply while the tree is built, so the dump can legitimately omit something you can see on the device. - It is the **same bounded tree** the driver's tree-walking strategies resolve against, which is why an element missing from the dump is also missing from an XPath result taken at the same moment. - It can be **large**. A long glossary list serialises every row it reaches, so a data-heavy screen can produce a dump measured in megabytes. - It is **per platform**, so a captured Android dump is not a reference for what an iOS locator should match. ## Reading a dump without wasting an afternoon 1. Ask for the source at the moment of interest, not after you have navigated on — the tree you want is the one that was on screen then. 2. Search the text for the glossary term you expected to match. If the string is not present, the next question is a snapshot question, not a selector question. 3. If it is present, compare the node's attributes with what your locator asserts, remembering that the two platforms publish different attribute names. 4. Change the locator only after those two checks, and re-dump after any change to the driver's snapshot settings. Appium can perform step one for you: `appium:printPageSourceOnFindFailure` is a core capability that makes the server emit the source when a find fails, on both platforms. ## Where this leaves you The page source is not a debugging luxury; it is the ground truth for element addressing. If a node is in the dump, some strategy can reach it. If it is not, no rewriting of an XPath, a predicate string or a class chain will conjure it, because those strategies resolve against the very tree that omitted it. Knowing the request, knowing that its output differs per platform, and knowing that iOS has a second door into the same snapshot is the junior-level ticket to every deeper conversation about locator durability.