Appium Visualizer

Desired capabilities

Capabilities are key-value pairs sent when a session starts that tell the Appium server what to automate: platformName, deviceName, app, automationName, appPackage and appActivity on Android, or bundleId on iOS. Get these right and the session starts; get one wrong and you get the classic "could not start a new session" error.

Drivers: UiAutomator2, Espresso and XCUITest

Appium does not automate devices directly — it delegates to platform drivers. On Android that is usually UiAutomator2 (or Espresso); on iOS it is XCUITest. Because Appium exposes the same WebDriver API on top of all of them, the same test structure can target both platforms with only the capabilities and locators changing.

The client-server architecture

Your test (the client) sends WebDriver commands to the Appium server, which translates them into native automation calls for the device through the chosen driver, then returns the result. Native, hybrid and mobile-web apps all flow through this same request path — for hybrid and web contexts, Appium switches into a WebView context so you can use familiar web locators.

How to use this tool

1. Set the desired capabilities for a target device in the tool.
2. Watch the session start and the driver initialise.
3. Send a command and follow it from client to server to device.
4. Switch between native and WebView contexts to see how hybrid apps are handled.

Worked example

Desired capabilities for an Android session look like this:

DesiredCapabilities caps = new DesiredCapabilities();
caps.setCapability("platformName", "Android");
caps.setCapability("deviceName", "Pixel_7");
caps.setCapability("automationName", "UiAutomator2");
caps.setCapability("app", "/path/to/app-debug.apk");

AppiumDriver driver = new AndroidDriver(
    new URL("http://127.0.0.1:4723/wd/hub"), caps);

Common mistakes to avoid

• Mismatched capabilities (wrong appPackage/appActivity) causing session start to fail.
• Using unstable XPath locators instead of accessibility ids, which are faster and more reliable on mobile.
• Forgetting to switch into the WebView context when testing hybrid app screens.
• Not resetting app state between tests, so one test's data leaks into the next.

Frequently asked questions

Related guides & tools