Appium

Appium 3 accepts a single top-level capabilities object holding alwaysMatch and firstMatch. The older desiredCapabilities and requiredCapabilities bodies are no longer accepted, and every Appium-specific key inside carries the appium: prefix.

WebDriverAgent is the on-device XCTest runner that Appium's XCUITest driver builds, signs, installs and launches. It holds Apple's automation APIs, so the driver never touches the app itself — it forwards every command to that agent over HTTP.

Appium speaks W3C WebDriver unchanged and adds four things: the appium: capability prefix, per-driver mobile: and flutter: execute methods, its own web-view context routes, and, in Appium 3, the deletion of many old /appium/ routes.

Appium 2 turned drivers into separately installed extensions, so the server package ships only the protocol layer and the extension machinery. Until you install a driver - UiAutomator2 for Android, XCUITest for Apple platforms - no session can start.

Appium's official appium-flutter-driver attaches over a WebSocket to the Dart VM Service that a running Flutter build publishes, and drives widgets through the ext.flutter.driver service extension registered by Flutter's test package.

On iOS, appium:deviceName together with appium:platformVersion picks a simulator by model and runtime. On Android the drivers accept the key but never select with it; appium:udid or appium:avd chooses the target there.

Two capabilities choose the driver: platformName and appium:automationName. Different keys choose the machine, and they differ by platform: appium:udid or appium:avd on Android, appium:deviceName with appium:platformVersion for an Apple simulator.

Three XCUITest capabilities: appium:xcodeOrgId names the Apple Developer team, appium:xcodeSigningId names the signing identity, and appium:updatedWDABundleId rebuilds the agent under a bundle identifier your provisioning profile covers. Android has no equivalent, because it has no provisioning profile.

The app capability takes a local path or http URL to one build artifact: an APK for Android, an IPA or .app bundle for iOS. Each driver reads the app identity from it - the Android package name, the iOS bundle id.

The Appium server refuses the session and answers with an invalid argument error naming the key. A non-standard capability with no colon namespace is illegal under the W3C protocol, so it is rejected rather than quietly ignored.

On Android the accessibility id strategy matches an element's content-desc. On iOS the XCUITest driver resolves it through the name attribute, which is the element's accessibilityIdentifier or, when that is empty, its visible localised label.

In Appium's iOS class chain strategy, a single slash requires the next element type to be a direct child of the previous match, while a double-star slash lets it sit at any depth below.

On Android the id strategy matches an element's resource-id, the package-qualified identifier fixed in the build. On iOS it is an alias for the name attribute, which XCUITest fills from the accessibility identifier. Same keyword, two unrelated attributes.

A React Native testID sets the iOS accessibilityIdentifier, which the XCUITest driver exposes behind the name attribute, and on Android it surfaces as the view's resource-id in the page source. Android's content-desc is filled by accessibilityLabel instead.

It sends a UiSelector expression as a plain string of chained Java-style calls. Appium's Android UiAutomator2 driver passes it to its on-device server, which parses the text and lets Google's UiAutomator framework match the live view hierarchy.

One pointer input source, and inside it the ticks that model the finger. The source declares an id and a pointer type of touch; the ticks are a move to the coordinate, a press and a lift.

On Android the UiAutomator2 driver scrolls while it searches: an -android uiautomator selector running UiScrollable scrollIntoView, or mobile: scroll. On iOS, XCUITest scrolls to an element you have already found, with mobile: scrollToElement.

The W3C Actions API replaced them: gestures now go to the actions endpoint. TouchAction is not gone from the clients — java-client still ships it marked deprecated — but the Appium 3 server no longer routes the old touch paths.

Both platforms answer POST /session/:sessionId/element/:elementId/value with a text field. On Android the UiAutomator2 agent performs the typing; on iOS WebDriverAgent does, at a rate the maxTypingFrequency setting bounds. Each driver adds its own typing methods.

Nothing in the chain holds the finger down. A pointer sequence advances one tick at a time, so a press is followed immediately by the lift. Insert a pause tick carrying the dwell between them.

On Android the UiAutomator2 driver exposes mobile: acceptAlert and mobile: dismissAlert; on iOS the XCUITest driver exposes mobile: alert, and only iOS also has the appium:autoAcceptAlerts capability that handles alerts without a call.

Sending browserName instead of an application makes the phone's own browser the app under test: Chrome on Android, whose page commands a Chromedriver answers, and Safari on iOS, driven by XCUITest through Apple's remote web inspector.

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.

Both sides share mobile: activateApp to foreground an app, mobile: backgroundApp to suspend it, mobile: terminateApp to stop it and mobile: queryAppState to check it. Android adds mobile: startActivity; Apple platforms add mobile: launchApp and mobile: killApp.

It tells the Android drivers to grant every permission the app declares as part of installing it, so no runtime prompt ever appears. It is an install-time switch decided at session start, and the XCUITest driver has no equivalent.

Both platforms answer the same W3C request, GET /session/:sessionId/screenshot, and return the whole screen as a base64-encoded PNG. Appium's UiAutomator2 driver on Android and its XCUITest driver on Apple platforms behave identically here.

Android needs developer options with USB debugging on and the host authorised, so the phone lists as online. Apple hardware needs Developer Mode enabled, the host trusted, and a signed WebDriverAgent the operating system will launch.

Only the endpoint changes: scheme, host, port and any base path. The Android and iOS capability sets travel unchanged — capabilities describe a device and a build, never a server. The catch: path-valued capabilities resolve on the server's filesystem.

Two different toolchains. On Android the drivers launch or attach to a named AVD and reach it over adb like any other Android target. On Apple the XCUITest driver boots a simulator with simctl, which requires a macOS host with Xcode.

Both are session-start capabilities, so on Android and on Apple real devices a language or locale change needs a new session. Apple simulators are the exception: XCUITest's mobile: configureLocalization changes localization inside a live session.

Mobile 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.

Turn the motion off at the device. On Android the appium:disableWindowAnimation capability drops the system animation scales for the session; on Apple platforms the XCUITest driver's reduceMotion setting asks the OS to prefer non-motion transitions.

The Inspector builds that list from GET /appium/sessions, which Appium gates behind the session_discovery insecure feature. Start the server with allow-insecure set to the scoped name *:session_discovery, or the list stays empty.

The Inspector's tree is a page-source snapshot from your last refresh, not a live view, and it is depth-capped by snapshotMaxDepth. Your test's find runs against its own fresh capture, so the two can honestly disagree.

Appium pulls device logs with POST /session/:sessionId/se/log, naming a type in the body. The Android drivers offer logcat and bugreport; the XCUITest driver offers syslog, crashlog and safariConsole. GET /session/:sessionId/se/log/types lists what a driver serves.