The Inspector, Capabilities & WebDriver Roots

What Appium Desktop Adds

Appium's server normally runs from the command line; Appium Desktop wraps it in a GUI for starting/stopping it and, most usefully, the Appium Inspector — a live view of a connected app's UI hierarchy for discovering element locators interactively rather than guessing at IDs while writing test code.

WebDriver Protocol Roots

Appium extends the same W3C WebDriver protocol architecture Selenium uses for browsers — testers already familiar with Selenium's session/element/command model find Appium's core concepts already familiar, just applied to mobile/desktop apps instead of browser pages.

Session & Capabilities

{
  "platformName": "Android",
  "automationName": "UiAutomator2",
  "deviceName": "Pixel_7_API_34",
  "app": "/path/to/app-debug.apk"
}

A session starts with these capabilities, then every command (find element, tap, type) happens within it until explicitly ended. automationName picks the platform-specific engine Appium builds on — UiAutomator2 for Android, XCUITest for iOS. A capabilities mismatch (wrong platformName for the connected device) fails the session before any test runs.

Native, Hybrid & Mobile Web

Native apps use the platform's own UI SDK; hybrid apps embed web content in a WebView; mobile web is a site viewed through a mobile browser. For hybrid apps, context switching (NATIVE_APP vs. WEBVIEW) tells Appium where to look — a locator that works in one context won't find an element that's actually in the other, a common source of "element not found" errors.