Appium Setup with Android Studio — Step-by-Step Guide

What You'll Set Up

This guide walks you through building the complete Appium testing environment on a fresh machine, using Android Studio as the Android toolchain. By the end of this guide you will have a fully working Appium setup capable of automating Android applications on both emulators and real devices — with every tool configured correctly and the relationships between them properly understood.

The Appium ecosystem for Android automation involves several interconnected tools: Android Studio provides the Android SDK, which contains the Android platform tools (ADB), the emulator, the build tools, and the system images that emulators run. The AVD Manager inside Android Studio lets you create and configure virtual devices. ADB (Android Debug Bridge) is the command-line tool that connects your machine to Android devices and emulators, and it is the transport layer that Appium uses to communicate with the device. Appium Server receives commands from your test scripts and sends them to UIAutomator2, which runs directly on the device. Appium Inspector is a desktop application that lets you inspect the element hierarchy of any running app, which you use to find the locators you need for your test scripts.

This guide is targeted at QA engineers who are either new to Android automation or setting up a machine from scratch for a new project. Every step includes the actual commands or UI steps required — there are no "configure as needed" hand-waves. If you follow this guide from beginning to end on a machine with a working internet connection, you will end up with a working Appium setup ready for test development.

The guide uses Python for the first-test example because Python is the most accessible language for a setup guide — shorter syntax, no compilation step, and an easier-to-read test structure. The same setup steps apply equally to Java, JavaScript, Ruby, or any other language supported by Appium's W3C WebDriver protocol. Only the test script code changes; the server, driver, and device configuration remain identical regardless of the language your tests are written in.

Installing Android Studio

Android Studio is the official IDE for Android development, but for QA purposes, you use it primarily for its bundled Android SDK components: the platform tools (ADB), the emulator, and the AVD Manager. You do not need to know Android development to use Android Studio as a QA tool — you only need the SDK components it installs.

Step 1: Download and Install

Go to developer.android.com/studio and download the installer for your operating system (macOS .dmg, Windows .exe, Linux .tar.gz). Run the installer and choose Standard installation when prompted. The Standard installation includes all the components you need: Android SDK, Android Emulator, Intel HAXM (on macOS/Windows for emulator hardware acceleration), and the default system image.

After the initial installation completes, Android Studio opens the SDK Manager automatically. Make sure the following components are installed (checked in the SDK Manager under the SDK Platforms and SDK Tools tabs):

• Android SDK Platform API 33 (Android 13) — the minimum recommended API level for new test projects
• Android SDK Platform API 34 (Android 14) — for testing against the latest Android version
• Android SDK Build-Tools (latest version)
• Android Emulator
• Android SDK Platform-Tools (contains ADB)
• Intel x86 Emulator Accelerator (HAXM installer) — only on Intel Mac/Windows

Step 2: Set Environment Variables

The most critical post-installation step is setting the ANDROID_HOME environment variable and adding the Android platform tools to your PATH. Without these, ADB will not be accessible from the terminal, and Appium will not be able to find the SDK tools it needs to manage devices.

# macOS — add to ~/.zshrc
export ANDROID_HOME=$HOME/Library/Android/sdk
export PATH=$PATH:$ANDROID_HOME/platform-tools
export PATH=$PATH:$ANDROID_HOME/emulator
export PATH=$PATH:$ANDROID_HOME/cmdline-tools/latest/bin

# Linux — add to ~/.bashrc
export ANDROID_HOME=$HOME/Android/Sdk
export PATH=$PATH:$ANDROID_HOME/platform-tools
export PATH=$PATH:$ANDROID_HOME/emulator
export PATH=$PATH:$ANDROID_HOME/cmdline-tools/latest/bin

# Windows — set via System Properties > Advanced > Environment Variables
# ANDROID_HOME = %LOCALAPPDATA%\Android\Sdk
# Add to PATH: %ANDROID_HOME%\platform-tools
# Add to PATH: %ANDROID_HOME%\emulator

# Reload shell configuration
source ~/.zshrc      # macOS
source ~/.bashrc     # Linux

# Verify installation
adb --version        # Should print: Android Debug Bridge version x.x.x
emulator -version    # Should print the emulator version

If adb --version returns "command not found" after setting environment variables and reloading the shell, the most common cause is that the SDK is installed in a different location than what you specified in ANDROID_HOME. In Android Studio, you can find the exact SDK location by going to Preferences (or Settings) → Appearance & Behavior → System Settings → Android SDK and reading the "Android SDK Location" field at the top of the panel. Copy that path exactly into your ANDROID_HOME variable.

Creating an Android Emulator (AVD)

An Android Virtual Device (AVD) is a software emulator that simulates a physical Android device on your computer. AVDs are extremely useful for development and testing because they are free, instantly available, easily reset to a clean state, and can simulate specific device hardware profiles and Android API levels without needing physical devices. For production testing, you should test on real devices too, but AVDs are ideal for development-time test writing and CI pipeline execution.

Creating an AVD via Android Studio

1. Open Android Studio and go to Tools → Device Manager (previously called "AVD Manager" in older versions).
2. Click the "+" or "Create Virtual Device" button.
3. Select a hardware profile. For general testing, Pixel 6 is recommended — it represents a modern mid-range device with a screen size and resolution common to real-world Android usage. Click Next.
4. Select a system image. Choose API 33 (Android 13, Google APIs) or API 34 (Android 14, Google APIs). If the image shows a download button, click it to download the system image — this may take several minutes. The "Google APIs" variants include Google Play services which some apps require. Click Next.
5. On the configuration screen, give the AVD a name (e.g., "Pixel_6_API_33"), set RAM to at least 2048 MB, and set internal storage to at least 2 GB (4 GB recommended for apps with large local storage). Click Finish.

Launching the Emulator

You can launch the emulator from the Device Manager by clicking the play button next to your AVD, or from the terminal using the emulator command-line tool. The terminal approach gives you more control over emulator options, which is important for CI environments:

# List all available AVDs
emulator -list-avds
# Output: Pixel_6_API_33

# Launch with audio and window (normal development use)
emulator -avd Pixel_6_API_33

# Launch without audio (prevents audio device errors in CI)
emulator -avd Pixel_6_API_33 -no-audio

# Launch headless for CI (no window, no audio, software GPU rendering)
emulator -avd Pixel_6_API_33 -no-audio -no-window -gpu swiftshader_indirect

# Wait for the emulator to finish booting before running tests
adb wait-for-device
adb shell getprop sys.boot_completed
# Returns "1" when fully booted, empty string or error if still booting

The -gpu swiftshader_indirect flag is important for headless CI environments. It forces the emulator to use software-based GPU rendering (Google's SwiftShader library) rather than hardware GPU acceleration. On CI machines without a GPU or on VMs where GPU passthrough is not available, hardware GPU rendering will fail silently or produce corrupted emulator output. SwiftShader is slower but runs reliably on any host machine. On a developer laptop with a dedicated GPU, omit this flag for better performance.

The boot completion check using sys.boot_completed is how you know the emulator is ready for ADB commands and Appium sessions. The emulator process starts quickly, but Android's init system takes 30-90 seconds to fully boot, depending on host hardware. Any ADB command or Appium session started before boot completes will fail or produce unexpected behavior. Always poll for sys.boot_completed == "1" rather than using a fixed sleep in scripts.

ADB Setup & Device Verification

ADB (Android Debug Bridge) is the command-line tool that enables communication between your computer and Android devices or emulators. Appium uses ADB internally for virtually every device interaction — installing and launching apps, pushing and pulling files, capturing screenshots, and collecting logcat output. Understanding ADB commands is essential for debugging Appium issues, because most Appium "can't find device" or "session creation failed" errors are ADB-level problems.

# Check connected devices and emulators
adb devices
# Healthy output:
# List of devices attached
# emulator-5554   device

# Get device information
adb -s emulator-5554 shell getprop ro.product.model    # Pixel 6
adb -s emulator-5554 shell getprop ro.build.version.sdk  # 33

# Install an APK to a specific device
adb install /path/to/app-debug.apk
adb -s emulator-5554 install /path/to/app.apk

# Find the app package name from an installed APK
aapt dump badging /path/to/app.apk | grep "package:"
# Output: package: name='com.example.myapp' versionCode='...' versionName='...'

# Find app package from the currently focused app on the device
adb shell dumpsys window | grep mCurrentFocus
# Output: mCurrentFocus=Window{... com.example.myapp/.MainActivity}

# Get the current foreground activity (useful for appActivity capability)
adb shell dumpsys activity activities | grep mResumedActivity
# Output: mResumedActivity: ActivityRecord{... com.example.myapp/.MainActivity}

# Clear all app data (equivalent to fresh install without reinstalling)
adb shell pm clear com.example.myapp

# Screen recording for debugging test failures
adb shell screenrecord /sdcard/test_recording.mp4
# Press Ctrl+C to stop, then pull the file:
adb pull /sdcard/test_recording.mp4 ./test_recording.mp4

# Logcat — real-time device logs (filter by app package)
adb logcat --pid=$(adb shell pidof com.example.myapp)

The adb devices command is the first thing to run whenever you encounter an Appium connection issue. The output should show your device serial with the status "device". If you see "unauthorized", it means the device is connected but has not granted USB debugging permission — accept the "Allow USB Debugging" dialog on the physical device screen. If you see "offline", there is a USB connection or driver issue (on Windows, this often means needing a manufacturer-specific ADB driver). If no devices appear at all, the device is not connected or ADB is not started — run adb start-server to start the ADB daemon.

Connecting a Real Android Device

While emulators are convenient for development and CI, real device testing is essential for validating actual user experience, hardware sensor behavior, camera functionality, and network performance. Real devices also reveal issues that emulators hide — fingerprint sensor interactions, NFC, Bluetooth connectivity, and carrier-specific settings that vary between device manufacturers.

Enable Developer Options and USB Debugging

1. Open Settings on the Android device.
2. Navigate to About Phone (on Samsung devices, this may be under Software Information).
3. Tap Build Number seven times in rapid succession. You will see a toast message counting down: "You are 3 steps away from being a developer", then "You are now a developer!".
4. Go back to Settings. A new Developer Options entry now appears, either directly under Settings or under Settings > System.
5. Open Developer Options and enable USB Debugging.
6. Connect the device to your computer with a USB cable.
7. On the device, a dialog will appear: "Allow USB debugging from this computer?" showing your computer's RSA fingerprint. Check "Always allow from this computer" and tap Allow.

Run adb devices after accepting the dialog. You should see the device's serial number with status "device". The serial number is what you use as the deviceName capability in your Appium test configuration.

Wireless Debugging (Android 11 and Later)

Android 11 introduced built-in wireless ADB debugging support that does not require a USB cable after the initial pairing. This is particularly useful when testing on a device that is mounted in a fixture or when USB cables create physical constraints.

# Step 1: On the device, go to:
# Developer Options → Wireless Debugging → Enable

# The screen shows: IP address and Port (e.g., 192.168.1.5:40351)
# It also shows a "Pair device with pairing code" option

# Step 2: Pair with pairing code
# Tap "Pair device with pairing code" on the device — it shows a 6-digit code
adb pair 192.168.1.5:40351
# Enter the 6-digit code when prompted
# Output: Successfully paired to 192.168.1.5:40351

# Step 3: Connect (use the main IP:Port shown on the Wireless Debugging screen)
adb connect 192.168.1.5:40351
# Output: connected to 192.168.1.5:40351

# Verify
adb devices
# Output:
# List of devices attached
# 192.168.1.5:40351  device

Note that wireless debugging requires both the device and your computer to be on the same Wi-Fi network. The connection speed is generally fast enough for Appium testing — the additional latency compared to USB is usually under 10ms and is not noticeable in test execution. However, for highly timing-sensitive tests or tests that transfer large amounts of data (like video streaming tests), USB may be preferable.

Installing Appium 2.x

Appium 2.x requires Node.js 18 or later. If you are on a fresh machine, install Node.js first using the official installer from nodejs.org or through a version manager like nvm (Node Version Manager), which allows you to switch between Node versions for different projects.

# Install Node.js via Homebrew (macOS)
brew install node
node --version   # Should be 18.x or later
npm --version    # Should be 9.x or later

# Install Appium globally via npm
npm install -g appium@latest
appium --version
# Example output: 2.5.1

# Start the Appium server on default port 4723
appium server --port 4723

# OR start with verbose debug logging (useful during setup)
appium --log-level debug

# Verify the server is running (in a separate terminal)
curl http://localhost:4723/status
# Expected output (JSON):
# {"value":{"build":{"version":"2.x.x","git-sha":"..."},...},"sessionId":null,"status":0}

The Appium server starts in the foreground and shows all incoming requests and responses in the terminal. This is intentional — during development, you want to see the server traffic to understand what your test scripts are sending. In production CI pipelines, you start Appium in the background (with & on Unix or as a service on Windows) and redirect its output to a log file.

One important change in Appium 2.x compared to Appium 1.x is that the server no longer bundles any drivers. This means a fresh Appium 2.x installation will reject any session creation request until you install at least one driver. The next section covers UIAutomator2 driver installation, which is the required step for Android automation.

UIAutomator2 Driver

UIAutomator2 is Google's official Android test automation framework and the driver that Appium uses to automate Android applications. Unlike Selenium, which controls a browser through browser-specific protocols, UIAutomator2 communicates directly with the Android accessibility service — the same system that powers screen readers and accessibility features. This means UIAutomator2 can automate any Android application regardless of how it was built or what technology stack it uses.

# Install the UIAutomator2 driver
appium driver install uiautomator2

# Verify the driver is installed
appium driver list --installed
# Output:
# ✓ uiautomator2@3.x.x [installed]

# Update the driver to the latest version
appium driver update uiautomator2

# Run Appium's built-in environment doctor
# This checks all prerequisites and reports anything missing
appium driver doctor uiautomator2

The appium driver doctor uiautomator2 command is one of the most useful tools for diagnosing setup issues. It checks for Java (required by UIAutomator2's Gradle build process), ANDROID_HOME, ADB availability, connected devices, and several other prerequisites. It prints a colored checklist showing which items pass and which fail, with instructions on how to fix each failing item. Running this command should be the first thing you do after installing Appium on a new machine or after making environment changes.

When UIAutomator2 creates a new Appium session with an Android device, it installs two APKs on the device that together form the UIAutomator2 server: io.appium.uiautomator2.server and io.appium.uiautomator2.server.test. These APKs run as a local HTTP server on the device, listening on a local port that Appium forwards through ADB. When your test script calls driver.find_element(), Appium sends an HTTP request to the UIAutomator2 server running on the device, which then calls the Android UIAutomator2 API to find the element in the current view hierarchy.

This architecture explains why UIAutomator2 requires ADB — the ADB port forwarding is how Appium Server communicates with the UIAutomator2 server running inside the device. If ADB connection is lost during a test run (USB cable disconnected, device sleeping, Wi-Fi dropout for wireless debugging), the Appium session will fail because the HTTP connection to UIAutomator2 is broken. This is why reliable USB cables and keeping devices awake during tests (via adb shell svc power stayon true) are important operational considerations.

Appium Inspector

Appium Inspector is a standalone desktop application that lets you visually inspect the element hierarchy of any Android or iOS application running on a connected device or emulator. It is the primary tool for finding element locators — the resource IDs, accessibility IDs, XPaths, and UIAutomator2 selectors that your Appium test scripts use to find and interact with elements. Without Appium Inspector, finding locators requires either reading the app's source code (which you may not have access to) or using Android Studio's Layout Inspector (which is more complex to configure for Appium testing purposes).

Installation

1. Go to github.com/appium/appium-inspector and click Releases on the right side.
2. Download the appropriate installer for your operating system: .dmg for macOS, .exe for Windows, .AppImage for Linux.
3. Install the application. On macOS, you may need to right-click and select "Open" on the first launch to bypass the Gatekeeper security warning for unsigned applications.

Connecting to a Session

1. Make sure Appium Server is running (appium server --port 4723 in a terminal).
2. Make sure your device or emulator is connected and visible to ADB (adb devices shows "device").
3. Open Appium Inspector. In the main window, configure the server connection:
   • Remote Host: 127.0.0.1
   • Port: 4723
   • Path: / (leave default)
4. In the Capabilities section, enter the capabilities for your app as JSON:

{
  "platformName": "Android",
  "appium:deviceName": "emulator-5554",
  "appium:appPackage": "com.saucelabs.mydemoapp.android",
  "appium:appActivity": ".MainActivity",
  "appium:automationName": "UIAutomator2",
  "appium:noReset": true
}

5. Click Start Session.
6. Appium Inspector launches the app on your device and captures a screenshot of the current screen. The left panel shows the screenshot, and the right panel shows the element attribute tree.

Note that in Appium 2.x, app-specific capabilities require the appium: prefix. The platformName is a W3C standard capability and does not need the prefix, but all Appium-specific capabilities like appPackage, appActivity, and automationName must be prefixed with appium: in the JSON format. Forgetting this prefix is the most common reason Appium Inspector sessions fail to start when users upgrade from Appium 1.x.

Inspecting App Elements

Once an Appium Inspector session is started, you have two ways to inspect elements: clicking on them in the screenshot view (left panel), or clicking on nodes in the element tree (right panel). Both methods highlight the corresponding element in the other panel and display the element's attributes in the attribute panel below the tree.

The attributes you care about most for writing Appium test locators are:

• content-desc: This is the Android accessibility description. It corresponds to the android:contentDescription attribute in the layout XML. Use this as AppiumBy.ACCESSIBILITY_ID (Python) or AppiumBy.accessibilityId() (Java). This is the most stable locator because developers set it intentionally and it is used by screen readers, making it unlikely to change for non-functional reasons.
• resource-id: This is the element's Android ID in the format com.package.name:id/element_id. Use the full string as AppiumBy.ID. Resource IDs are stable within a version of the app but can change between versions if the layout is refactored.
• text: The visible text content of the element. Use in XPath: //android.widget.TextView[@text='value']. Text-based locators are fragile for localized apps where UI text changes between language settings.
• class: The Android widget class (e.g., android.widget.Button, android.widget.TextView). Use as AppiumBy.CLASS_NAME only for very generic element selection — most screens have many elements of the same class, making this locator ambiguous.

The translation from Inspector attributes to test code locators follows a consistent pattern:

# Inspector shows: content-desc="open menu"
# → Python code:
driver.find_element(AppiumBy.ACCESSIBILITY_ID, "open menu")
# → Java code:
driver.findElement(AppiumBy.accessibilityId("open menu"));

# Inspector shows: resource-id="com.example:id/loginButton"
# → Python code:
driver.find_element(AppiumBy.ID, "com.example:id/loginButton")
# → Java code:
driver.findElement(AppiumBy.id("com.example:id/loginButton"));

# Inspector shows: text="Log In" (no content-desc or resource-id)
# → Python code:
driver.find_element(AppiumBy.XPATH, "//android.widget.TextView[@text='Log In']")
# → Java code:
driver.findElement(AppiumBy.xpath("//android.widget.TextView[@text='Log In']"));

The Appium Inspector also has a Tap button in the element action panel. After selecting an element, you can click Tap to have the Inspector tap that element on the device. This allows you to verify that your selected element is the correct one before writing any code, which saves significant time during test development. If the element responds as expected when tapped via Inspector, your locator is correct and you can confidently use it in your test script.

The Search functionality in the element tree panel allows you to search for elements by text, content-desc, or resource-id. This is useful when the app has a complex hierarchy and you want to quickly jump to the element you are looking for without expanding each node manually. Type the search term and the Inspector highlights all matching elements in the tree.

Running Your First Test

With Android Studio installed, an emulator running, Appium server active, and UIAutomator2 driver installed, you are ready to write and run your first automated test. The example below uses Python with the Appium Python Client and the Sauce Labs My Demo App, which is a freely available Android APK designed for automation practice. Download the APK from the Sauce Labs GitHub repository before running this test.

# Install required Python packages
pip install Appium-Python-Client
pip install selenium

from appium import webdriver
from appium.options import UiAutomator2Options
from appium.webdriver.common.appiumby import AppiumBy
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

# Configure capabilities
options = UiAutomator2Options()
options.platform_name = "Android"
options.device_name = "emulator-5554"    # or real device serial from adb devices
options.app_package = "com.saucelabs.mydemoapp.android"
options.app_activity = ".MainActivity"
options.no_reset = True
options.auto_grant_permissions = True

# Connect to Appium server and start session
driver = webdriver.Remote("http://127.0.0.1:4723", options=options)
wait = WebDriverWait(driver, 15)

try:
    # Open the navigation menu
    wait.until(EC.element_to_be_clickable(
        (AppiumBy.ACCESSIBILITY_ID, "open menu"))).click()

    # Navigate to the Login screen
    wait.until(EC.element_to_be_clickable(
        (AppiumBy.XPATH, "//android.widget.TextView[@text='Log In']"))).click()

    # Enter username
    driver.find_element(
        AppiumBy.ACCESSIBILITY_ID, "Username input field").send_keys("bod@example.com")

    # Enter password
    driver.find_element(
        AppiumBy.ACCESSIBILITY_ID, "Password input field").send_keys("10203040")

    # Tap the Login button
    driver.find_element(
        AppiumBy.ACCESSIBILITY_ID, "Login button").click()

    # Wait for the welcome message and verify login was successful
    welcome_element = wait.until(EC.presence_of_element_located(
        (AppiumBy.XPATH, "//android.widget.TextView[@text='Bob']")))

    print("Test PASSED: Welcome message visible —", welcome_element.text)

except Exception as e:
    print("Test FAILED:", str(e))
    # Capture screenshot on failure
    driver.save_screenshot("failure_screenshot.png")

finally:
    # Always quit the driver to close the Appium session
    driver.quit()

Before running this script, make sure: the emulator is running and visible in adb devices, the Appium server is running on port 4723, and the My Demo App APK is installed on the emulator (install it with adb install MyDemoApp.apk if needed). Then run the script with python test_login.py. You should see the app launch on the emulator, the menu open, the login screen appear, credentials entered automatically, and the welcome message display — all automated by your script.

The try/except/finally pattern is important: putting the test assertions in the try block, error handling in except, and driver.quit() in finally ensures the Appium session is always closed, even if the test fails with an exception. If you omit the finally block and the test fails, the session remains open on the Appium server and the emulator stays locked to that app. Over time, accumulated zombie sessions consume memory and can cause subsequent test runs to fail with "too many sessions" errors.

Common Setup Issues & Fixes

Every QA engineer setting up Appium for the first time encounters the same set of problems. The table below covers the most common issues and their solutions, saving you hours of searching through GitHub issues and Stack Overflow threads.

Best Practices

These recommendations come from real project experience — the habits that make the difference between a testing environment that works reliably every day and one that requires constant troubleshooting.

1. Set ANDROID_HOME before starting Appium. Appium needs ANDROID_HOME to locate ADB and other SDK tools. If the environment variable is not set in the session where you start Appium, the server will start but fail when creating sessions with cryptic "Unable to find adb" errors. Always verify with echo $ANDROID_HOME before starting the server.

2. Always run adb devices before running tests. Make it a habit. A one-second check that confirms your device is connected saves potentially minutes of debugging a "session creation failed" error that has a completely obvious cause.

3. Use appium driver doctor uiautomator2 for new setups. The doctor command checks all prerequisites and tells you exactly what is missing with actionable fix instructions. It is the fastest way to diagnose environment setup issues on a new machine or after a software update that may have changed path configurations.

4. Keep UIAutomator2 driver updated. The UIAutomator2 driver is updated frequently to track Android changes and fix compatibility issues with new API levels. Run appium driver update uiautomator2 when setting up a new project or when encountering session failures on newer Android versions.

5. Use Appium Inspector before writing tests. Never guess locators. The Inspector shows you exactly what attributes are available for every element, lets you verify that the locator works by tapping the element directly, and copies the locator in your chosen programming language. A 5-minute Inspector session saves an hour of test debugging.

6. Store capabilities in a config file. Never hardcode appPackage, appActivity, deviceName, or Appium server URL directly in test files. Store them in a JSON, YAML, or Python config file and read them at runtime. This makes your framework portable across machines and environments without code changes.

7. For CI, use pre-built AVDs or cloud devices. Creating an emulator in a CI pipeline from scratch takes 5-10 minutes and can fail if the required system images are not cached. Pre-building AVDs in a custom CI agent image, or using a cloud device service like BrowserStack, Sauce Labs, or AWS Device Farm, eliminates this setup time and makes CI runs faster and more reliable.

8. Keep devices awake during test runs. Android devices can enter sleep mode if idle for the configured timeout period, interrupting ADB connections and causing test failures. Prevent sleep during automated testing with adb shell svc power stayon true before running tests and adb shell svc power stayon false in your teardown. For emulators, configure the screen timeout to a high value in the AVD settings.

9. Log the device model and Android version at session start. Include a log statement at the start of every test session that records the device serial, model name, and Android version. When tests fail in a multi-device environment, knowing which specific device failed makes diagnosis much faster. Use driver.capabilities to access these values from your test code after session creation.

10. Add a "wait for app to be ready" function. Before any test action, wait for a stable landmark element on the app's home screen to confirm that the app has fully loaded. This single pattern prevents the most common category of intermittent failures — false "element not found" errors caused by tests beginning before the app's initial loading is complete. Make this function part of your base test setup rather than optional per-test logic.