Appium Inspector Tutorial: Setup, Features & Best Practices

A mobile app can look perfectly clear to a human tester while remaining difficult for an automation script to understand.

You see a Sign In button. Appium sees an element somewhere inside a large XML hierarchy. Before the test can tap that button, it needs a reliable way to identify it. That could be a resource ID, accessibility ID, class name, Android UIAutomator selector, or XPath.

This is where Appium Inspector helps.

Appium Inspector gives testers a visual way to explore an application's interface, examine element attributes, test locators, interact with the app, and record actions before adding them to an automation script. It turns the app's underlying page source into something testers can inspect rather than guess at.
This Appium Inspector tutorial explains how the tool works, why teams use it, how to configure a session, and which Appium Inspector capabilities for Android are important when testing locally or on remote devices.

What Is Appium Inspector?

Appium Inspector is a graphical client for Appium. It connects to an Appium server and displays the application under test as both:

• A current screenshot of the app
• A structured representation of its page source

Selecting an element in the screenshot highlights the corresponding node in the source tree. Selecting a node in the source tree reveals its attributes, available actions, and suggested locators.
Appium Inspector is essentially an Appium client with a graphical interface. It sends commands to an Appium server in much the same way that a test script does. The server then passes those commands to the appropriate platform driver, such as UiAutomator2 for Android or XCUITest for iOS.

The interface has two main areas:

1. Session Builder
This is where you enter the Appium server address and define the capabilities needed to create a session.
2. Session Inspector
This appears after the session starts. It provides the application screenshot, XML source, selected element details, commands, gestures, recording tools, and session information.
Appium Inspector is not the Appium server, a complete test framework, or a replacement for test code. It is a development and debugging tool that helps you understand the application interface and build better automation.
It is also no longer bundled inside the discontinued Appium Desktop package. The official project distributes it separately as a standalone desktop application and as an Appium server plugin.

Why Use Appium Inspector?

Writing a mobile automation script without inspecting the app first often leads to trial and error.
A tester may copy visible text into an XPath, rerun the test, wait for the session to start, and discover that the locator matched the wrong element. The process repeats until something works, but the final locator may still be unstable.
Appium Inspector provides a faster way to answer the questions that come up while building mobile tests:

• Which attributes does this element expose?
• Does it have a unique accessibility ID or resource ID?
• Is the element inside the native app or a web view?
• Can Appium interact with it?
• Does the selected locator return the correct element?
• What changed after the latest UI update?
• Is the page source refreshed to the current screen?
• Does the same element appear differently on another device?

You can select an element, review its properties, try a locator, and perform an action before putting that logic into a full test suite.
This makes Appium Inspector especially useful during test development, script maintenance, and element-related debugging.

Benefits of Appium Inspector

1. Faster Element Identification
Appium Inspector presents the application source as a navigable tree instead of requiring testers to read raw XML.
Clicking an element in the tree highlights it in the screenshot. The selected element panel then displays its available attributes and locator suggestions. This makes it easier to identify buttons, text fields, images, menus, and other controls.

2. Better Locator Selection
A locator that works once is not necessarily a good locator.
For example, an absolute XPath tied to the element's exact position may fail when the development team adds another container to the screen. A unique accessibility ID or resource ID is usually less dependent on the surrounding layout.
Appium Inspector lets testers compare the available attributes before deciding which locator belongs in the test. It can also search for elements using locator strategies supported by the active driver and show suggested selectors.
The suggestions should still be reviewed. Generated XPath expressions are useful for exploration, but they are not automatically the most maintainable choice.

3. Interactive Validation
Testers can interact with elements directly from the Inspector.
Depending on the active driver and element, available actions may include:

• Tapping or clicking
• Entering text
• Clearing text
• Swiping
• Executing custom gestures
• Triggering device controls
• Running driver commands

This helps confirm that Appium can perform the intended action before the same command is added to a test.

4. Faster Script Prototyping
Appium Inspector can record supported interactions and translate them into executable Appium client code.
The Recorder tab supports selecting a target language, displaying optional boilerplate, copying the generated code, and changing the language after actions have been recorded.
Recorded output is best treated as a starting point. Production tests still need appropriate waits, assertions, reusable methods, error handling, test data, and cleanup logic.

5. Easier Debugging
When a test cannot locate or interact with an element, Appium Inspector helps separate several possible causes:

• The locator is incorrect
• The element is not currently present
• The page source is outdated
• The app has switched contexts
• The element exists but is not interactable
• The wrong screen or activity was launched
• The session was created with incorrect capabilities

Instead of repeatedly changing the test script, testers can recreate the state and examine what Appium sees.

6. Support for Native and Hybrid Workflows
Appium Inspector starts in the native application context. For hybrid apps, testers can use its context controls to discover and switch between native and web-view contexts when those contexts are available.
This is useful when a user journey moves from a native screen to embedded web content, such as a payment page, authentication flow, or help centre.

7. Reusable Session Configuration
Server details and capability sets can be saved for later sessions. Testers can also attach the Inspector to an existing Appium session instead of creating a new one.
This reduces repeated setup when teams regularly inspect the same devices, applications, or test environments.

How to Get Started With Appium Inspector?

The exact setup depends on the platform being tested. The following process uses Android and the UiAutomator2 driver as the main example.

Step 1: Install the Required Software
For a local Android setup, you will generally need:

• A supported version of Node.js
• npm
• Appium
• Android SDK tools
• Java Development Kit
• UiAutomator2 driver
• An Android emulator or physical device
• Appium Inspector

Current Appium server requirements include Windows, macOS, or Linux, a supported Node.js release, and npm 10 or later. Platform drivers may have additional SDK and development-tool requirements.

Step 2: Install Appium
Install the Appium server globally through npm:
npm install -g appium
Confirm that Appium is available:
appium - version
Appium does not include platform drivers automatically. Installing the server alone is therefore not enough to automate Android or iOS.

Step 3: Install the Android Driver
Install UiAutomator2 using the Appium Extension CLI:
appium driver install uiautomator2
UiAutomator2 is the primary Appium driver for automating native, hybrid, and mobile web applications on Android devices and emulators.
You can check the Android setup using Appium Doctor:
appium driver doctor uiautomator2
The command reports missing required dependencies and may also suggest optional improvements.

Step 4: Prepare the Android Device

• For a physical Android device:
• Enable Developer Options.
• Enable USB debugging.
• Connect the device to the computer.
• Approve the USB debugging prompt on the device.
• Run the following command:

adb devices -l
The device should appear as online. Its identifier can be used as the value of appium:udid.
For an emulator, create and start an Android Virtual Device through Android Studio before beginning the Inspector session.

Step 5: Install Appium Inspector
Download the appropriate standalone application from the official Appium Inspector GitHub releases page.
The desktop application is available for Windows, macOS, and Linux. The Inspector can also be installed as an Appium server plugin, although the standalone application is usually the simplest option for individual testers.

Step 6: Start the Appium Server
Open a terminal and run:
appium
By default, a local Appium server will normally be available at:
http://127.0.0.1:4723
Keep the terminal open while using Appium Inspector. The Inspector needs an active local or remote Appium server before it can create a session.

Step 7: Enter the Server Details
Open Appium Inspector.
For a local server using its default configuration, keep the standard server details:
SettingValueRemote Host127.0.0.1Remote Port4723Remote PathDefault or emptySSLDisabled
The default configuration connects to http://127.0.0.1:4723.
Use /wd/hub only when connecting to Appium 1 or a newer Appium server that was explicitly started with /wd/hub as its base path.

Step 8: Add the Session Capabilities
Enter the capabilities through the form-based capability builder or paste them as JSON.
Here is a basic example for inspecting an APK on an Android emulator:
{
 "platformName": "Android",
 "appium:automationName": "UiAutomator2",
 "appium:udid": "emulator-5554",
 "appium:app": "C:\apps\sample-app.apk"
}
To inspect an application that is already installed, use its package and activity instead:
{
 "platformName": "Android",
 "appium:automationName": "UiAutomator2",
 "appium:udid": "emulator-5554",
 "appium:appPackage": "com.example.app",
 "appium:appActivity": ".MainActivity",
 "appium:noReset": true
}
Replace the sample values with the actual device ID, package, activity, and application path.

Step 9: Start the Session
Select Start Session.
Appium Inspector sends the capabilities to the server. The Appium server then selects the requested driver, connects to the target device, and opens the specified application.
If the session starts successfully, the Session Inspector displays the current screenshot and application source.

Step 10: Inspect and Test Elements
Select an element from either the screenshot or the source tree.
Review:

• Resource ID
• Accessibility description
• Text or value
• Class
• Bounds
• Enabled state
• Selected state
• Clickable state
• Suggested locators

You can then test the locator, interact with the element, record an action, or copy the relevant selector into your automation project.
Refresh the source whenever the app changes outside the Inspector. Interacting with the application directly on the device does not necessarily refresh the XML shown in the Inspector.

Step 11: End the Session
Close the session after inspection is complete.
Leaving unnecessary sessions running can keep devices occupied, preserve unwanted app state, or prevent another test from using the same local or remote device.

Use Cases for Appium Inspector

1. Finding Locators Before Writing a Test
A tester can open each important screen, inspect its elements, and identify suitable locators before building page objects or test methods.
This is particularly useful for login forms, navigation menus, search fields, filters, checkout screens, media controls, and other frequently automated components.

2. Debugging Element-Not-Found Failures
When a previously working test fails, the tester can recreate the screen in Appium Inspector and check whether:

• The locator attribute changed
• The element moved into another container
• The test opened the wrong screen
• The app entered a web-view context
• The element appears only after scrolling
• The element is missing from the returned source

This provides more useful information than simply increasing the wait time or rerunning the test.

3. Comparing Android and iOS Interfaces
Teams supporting both platforms can use the same general inspection workflow while reviewing the different element attributes exposed by UiAutomator2 and XCUITest.
The actual locators may differ because Android and iOS use different UI frameworks. Appium Inspector makes those differences easier to see before teams attempt to force identical selectors into both test suites.

4. Inspecting Hybrid Applications
A hybrid application may contain native navigation and embedded web content within the same journey.
Appium Inspector can help testers identify the available contexts and switch between them. This is useful when the same test must move from native controls into a web view and back again.

5. Prototyping Gestures
The Gestures tab allows testers to create, save, import, execute, and edit custom gestures.
This can help when developing tests for:

• Carousels
• Sliders
• Drag-and-drop controls
• Maps
• Drawing areas
• Long scrolling pages
• Multi-step swipe interactions

The resulting gesture should still be tested across different screen sizes and orientations before being used broadly.

6. Reviewing Accessibility Attributes
Appium Inspector can reveal accessibility-related attributes such as accessibility IDs and Android content descriptions.

This helps automation engineers determine whether developers have exposed stable, meaningful identifiers. However, inspecting these attributes does not replace dedicated accessibility testing, assistive-technology validation, or standards-based audits.

7. Maintaining Tests After UI Changes
When a new release changes the screen hierarchy, testers can compare the updated source with the locators used by existing tests.
This makes it easier to update page objects deliberately rather than patching individual failing tests one at a time.

8. Exploring Driver Commands
The Commands tab displays commands and execute methods available through the active Appium driver and compatible plugins. The available options therefore change according to the session configuration.
This can help testers explore driver behavior before implementing the same command in code.

9. Inspecting Remote Real Devices
Appium Inspector can connect to a remote Appium-compatible server as well as a local one.
This allows teams to inspect applications on remotely hosted real devices rather than limiting element exploration to a local emulator or the devices physically available to the tester.

How to Open the Appium Inspector in Windows?

Appium Inspector supports Windows 10 and later versions.
Follow these steps to install and open it:
1. Download the Windows Installer

Open the official Appium Inspector releases page and download the .exe installer that matches your system.
The .exe version is recommended for Windows because it supports update checking.

2. Handle the Windows Security Warning

The application may trigger a Windows warning because the installer is not currently signed.
You can unblock it before installation:

• Right-click the downloaded installer.
• Select Properties.
• Select the Unblock checkbox.
• Click OK.
• Run the installer.

Alternatively, open the installer, select More info, and then choose Run anyway when that option appears. Only bypass the warning after confirming that the installer came from the official Appium Inspector repository.

3. Complete the Installation

Follow the installation wizard and choose the required installation location.
After installation, search for Appium Inspector from the Windows Start menu and open it.

4. Start Appium Separately

Opening Appium Inspector does not automatically create a usable automation environment.
Before starting an Inspector session:

• Start an emulator or connect a physical device.
• Confirm that the device appears in ADB.
• Start the Appium server by running appium.
• Verify that the required Android driver is installed.
• Open Appium Inspector.
• Enter the server details and capabilities.
• Select Start Session.

5. Check the Remote Path

For a default current Appium server, use the default Inspector path rather than automatically entering /wd/hub.
An incorrect remote path is a common reason for receiving a session-creation error even when the Appium server is running.

What Are Appium Inspector Capabilities in Android?

Appium Inspector capabilities are the key-value pairs used to describe the session you want Appium to create.
They tell the Appium server which platform, driver, device, and application should be used. Capabilities are fixed when the session begins and cannot be changed during that session.
These settings are not exclusive to Appium Inspector. The same capabilities are used when creating sessions from Appium test scripts.
Under the W3C WebDriver standard, Appium-specific capabilities use the appium: namespace. Standard capabilities such as platformName do not need that prefix.

Common Appium Inspector Capabilities for Android

UiAutomator2 recommends using appium:udid for selecting real devices and appium:avd for selecting emulators. Its appium:deviceName value is not normally used to identify the Android device.
If appium:app is provided, UiAutomator2 can often detect the package and activity from the application file. When inspecting an already installed app, appium:appPackage and appium:appActivity tell the driver which application to start.

Example for an Installed Android App

{
 "platformName": "Android",
 "appium:automationName": "UiAutomator2",
 "appium:udid": "R58M123ABCD",
 "appium:appPackage": "com.example.shopping",
 "appium:appActivity": ".MainActivity",
 "appium:noReset": true
}

Example for Installing an APK

{
 "platformName": "Android",
 "appium:automationName": "UiAutomator2",
 "appium:udid": "emulator-5554",
 "appium:app": "C:\builds\shopping-app.apk",
 "appium:autoGrantPermissions": true
}

Example for Mobile Chrome

{
 "platformName": "Android",
 "appium:automationName": "UiAutomator2",
 "appium:udid": "emulator-5554",
 "browserName": "Chrome"
}
Do not include both browserName and appium:app in the same UiAutomator2 session. One requests a browser session, while the other requests an installable application.

noReset and fullReset
These capabilities affect application state:
appium:noReset: true prevents the usual reset behaviour and preserves the app's existing data.
appium:fullReset: true uninstalls the application before the session starts.

They should not be added automatically to every session. Use noReset when preserving state is intentional, such as inspecting a screen that requires an existing login. Use fullReset when the test requires a clean installation.

Why Use HeadSpin With Appium Inspector?

HeadSpin extends the Appium Inspector workflow to real devices available through its testing infrastructure.

The HeadSpin Platform includes an inbuilt Appium Inspector for dynamically validating UI elements. Teams can inspect applications on real Android and iOS devices across different models, OS versions, and locations without maintaining every device locally.

HeadSpin also supports Appium automation, ADB access for Android debugging, and centralized session analysis. This allows teams to move from element inspection to real-device test execution and troubleshooting within the same testing environment.

Conclusion

Appium Inspector removes much of the guesswork from mobile test development.

Instead of repeatedly editing a script to discover which locator or capability works, testers can inspect the page source, evaluate element attributes, try interactions, compare locators, and confirm the session configuration through a graphical interface.

Its greatest value is not automatic code generation. It is visibility.
Appium Inspector shows what the Appium driver can actually see and interact with. That makes it useful when creating new tests, debugging failed locators, maintaining existing automation, inspecting hybrid applications, and working with local or remote devices.

It should still be used with sound automation practices. Choose stable locators, review recorded code, add explicit synchronization, keep tests independent, and validate important journeys on the devices your users rely on.

Originally Published:- https://www.headspin.io/blog/appium-inspector-guide