2.3- Mobile Testing

Mobile Testing — Appvance IQ documentation.

Mobile Testing

Contents

Mobile Designer, AIQ’s test design technology for native mobile apps, allows dev teams to take a mobile-first approach with their testing to meet their customers’ mobile-first mindset. Its innovative visual accessor approach overcomes the limitations of other locators used by Appium, giving AIQ a more robust technical approach.

AISG + Automatic Regression Testing for mobile means teams can also leverage AIQ’s cutting-edge autonomous testing approach.

AIQ provides testing for native mobile, mobile web, and hybrid apps in iOS and Android. It covers all your test needs, including functional, API, performance, and load tests to ensure your users have an optimal experience.

Mobile Designer enables script recording and playback, a simpler approach to mobile test design than traditional mobile scripting. Click By Image allows Mobile Designer to incorporate screenshots into scripts.

AISG for mobile automatically identifies locators which can then be used in Mobile Designer scripts, making test creation even easier.

Last updated: April 13, 2023

If you have any feedback on this topic, please contact us at documentation@appvance.ai

Mobile Designer New Interface - Legacy Overview

Legacy reference

This page describes a Mobile Designer interface that should be considered legacy unless a customer is still maintaining older assets. Current guidance should use AIQ mobile testing and Scenario Editor terminology.

Use this page for

Current recommendation

  1. Use active Mobile Testing and Scenario Editor articles for new work.
  2. Move still-useful migration notes into current pages.
  3. Remove outdated screenshots, old navigation labels, and unsupported instructions.
  4. Archive this page when legacy support is no longer required.

Last updated: October 7, 2026

Mobile Designer Classic - Legacy Reference

Legacy reference

Mobile Designer Classic should be treated as legacy documentation. Keep this page only for teams maintaining older mobile testing assets. Current mobile testing guidance should use Scenario Editor and current AIQ mobile terminology.

When this page is useful

Current recommendation

  1. Create new mobile tests using current AIQ mobile testing workflows.
  2. Move useful migration guidance into active Mobile Testing or Scenario Editor pages.
  3. Remove obsolete screenshots, product names, and unsupported feature references.
  4. Archive or delete this page when no supported legacy use remains.

Last updated: October 7, 2026

Mobile Testing Configurations in AIQ

Mobile testing configuration should define the device, platform, application build, automation framework, network access, permissions, and evidence requirements before execution. Keep configurations explicit so failures can be reproduced.

Configuration areas

Maintenance workflow

  1. Start with a smoke test on one known-good device.
  2. Expand to device pools only after configuration is stable.
  3. Review configuration after app, OS, browser, driver, or AIQ upgrades.
  4. Document deviations from the standard mobile environment.

Last updated: October 6, 2026

Get Started with Android Testing in AIQ

Get Started with Android Testing in AIQ

Use this checklist to prepare Android testing with AIQ. Exact device, emulator, and driver requirements can vary by AIQ release, so confirm the release-specific prerequisites before execution.

Setup checklist

Validation steps

  1. Confirm the device is visible to the execution host.
  2. Run a small smoke test before building longer scenarios.
  3. Review output, screenshots, and logs for device or environment failures.
  4. Document device model, OS version, application build, and AIQ version when reporting issues.

Last updated: September 18, 2026

Getting Started with iOS and AIQ

Requirements

  1. Mac OS X
    At this time Catalina 10.15.3 required. This is to evolve as Mac OS X evolves.

  2. iOS Simulator compatible App file

  3. AIQ Controller locally installed on Mac

Setup

Install and Setup Xcode

  1. Download, install and open Xcode for first time.

  2. Make sure to accept the End User License Agreement.

  3. Make sure to install additional components.

  4. To view installed Simulators or connected physical iPhones

    1. Open Xcode, select Window > Devices and Simulators

    2. Click Simulators and select any model

    3. Note the iOS version number, Identifier value and Model name for later use. These correspond to platformVersion, udid and deviceName capabilities.
      For example:

  5. Sign into your Apple account (Required if test will use physical iPhones. Skip this step if test uses Simulators)

    1. Select Xcode > Preferences > Accounts

    2. Click +

    3. Select Apple ID and click Continue

    4. Enter your Apple ID (must be a paying Account so Team ID value is assigned to Membership) and follow prompts until account appears in Accounts list

  6. Create a new Xcode Project (This step is only to test connection between Mac and Simulator or physical iPhone. Can be skipped)

    1. Open Xcode > File > New > Project

    2. Select iOS > Single View App and click Next

    3. Enter a name in the Project Name box

    4. Select a Team

    5. Enter a name in the Organization Name box

    6. Enter com.<anything> in the Organization Identifier box (I used com.appvance)

      • Bundle identifier appears as com.appvance.ProductName

    7. Leave the remaining options as default

    8. Click Next

    9. Specify the location to save the Project and click Create

    10. Press Play and confirm the Application launches in the Simulator or physical iPhone and displays your Hello World! app. You can change the Simulator or physical iPhone by clicking on the device name.

    11. Drag and drop any iOS Application file (have .app extension) to install to the Simulator

    12. Confirm just installed Application runs successfully

    13. Press Command + Q to stop the Simulator

    14. Press Command + Q to close Xcode

Install Homebrew

  1. Open Terminal

  2. Run the following command

    /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"

Appium Pre-requisites and Install

  1. Open Terminal

  2. Run the following commands in the order listed below

brew update
brew install libimobiledevice
brew install ios-deploy
brew install carthage
brew install appium

Configure your Appium Server Simulator configuration file

The Appium Server Simulator configuration file must be updated for your specific environment and Application. This is a JSON file that contains an array of objects. Each object corrresponds to a machine which has Appium running and the Simulator installed. The required keys and values of each object are:

{
  “serverURL”: “http:/example.com:4723/wd/hub, URL in which Appium runs”,
  “proxyURL”: “http://example.com:9090, optional, URL in which Test Designer runs”,
  “capabilities”: {
    “platformVersion”: “13.1, must correspond to one of installed Simulators”,
    “udid”: “some identifier, must correspond to one of installed Simulators”,
    “wdaLocalPort”: “8100 - 8199, to automate multiple Simulators or physical iPhones”,
    “deviceName”: “iPhone 8, must correspond to one of installed Simulators”
  },
  “app”: “Absolute path to where .app file is in local file system or URL of .app file, needed if value for bundleId is empty”,
  “bundleId”: “Bundle ID of AUT, needed if value for app is empty, otherwise is optional if value for app is not empty”
}

0. Download the ios-simulator.json file and open it in an editor

  1. Update the platformVersion to match the version of the Simulator.

  2. Replace the udid value in the template with the Identifier number noted during the Xcode setup.

  3. Update the bundleId to match your Application’s bundleId.
    How to find the Bundle ID?

    1. Right-click .ipa file and select Show Package Contents

    2. Look for a file ending in .plist

    3. Open the located file with a text editor

    4. Locate the Bundle ID, often a key containing the string BundleID or BundleIdentifier

    5. Locate a string tag similar to com.companyname.Appname

    6. Rename the configuration file to an app-specific name and save
      Save it someplace you’ll remember, for example with AIQ assets.

Configure your Appium Server physical iPhone configuration file

The Appium Server Simulator configuration file must be updated for your specific environment and Application. This is a JSON file that contains an array of objects. Each object corrresponds to a machine which has Appium running and the physical iPhone connected. For iOS physical devices 3 additional capabilities are needed:

String representing Apple developer team identifier. The Team ID is a unique 10-character string generated by Apple that is assigned to your team. You can find your Team ID using your developer account. Sign in to developer.apple.com/account, and click Membership in the sidebar. Your Team ID appears in the Membership Information section under the team name. You can also find your Team ID listed under the "Organizational Unit" field in your iPhone Developer certificate by opening Keychain Access app, click My Certificates in Category section and clicking appropriate certificate to show its details.

String representing a signing certificate. This is usually just ‘iPhone Developer’ without quotes.

String representing Bundle ID to update WDA before building and launching on real devices. This is usually just ‘com.facebook.WebDriverAgentRunner’ without quotes.


The required keys and values of each object are:

{
  “serverURL”: “http:/example.com:4723/wd/hub, URL in which Appium runs”,
  “proxyURL”: “http://example.com:9090, optional, URL in which Test Designer runs”,
  “capabilities”: {
    “platformVersion”: “13.1, must correspond to one of connected physical iPhones”,
    “udid”: “some identifier, must correspond to one of connected physical iPhones”
    “wdaLocalPort”: “8100 - 8199, to automate multiple Simulators or physical iPhones”,
    “deviceName”: “iPhone 8, can be whatever name”,
    “xcodeOrgId”: “Team ID”,
    “xcodeSigningId”: “iPhone Developer”,
    “updatedWDABundleId”: “com.facebook.WebDriverAgentRunner”
  },
  “app”: “Absolute path to where .ipa file is in local file system or URL of .ipa file, needed if value for bundleId is empty”,
  “bundleId”: “Bundle ID of AUT, needed if value for app is empty, otherwise is optional if value for app is not empty”
}

0. Download the ios-physical.json file and open it in an editor

  1. Update the platformVersion to match the version of the physical iPhone.

  2. Replace the udid value in the template with the Identifier number noted during the Xcode setup.

  3. Update the bundleId to match your Application’s bundleId.
    How to find the Bundle ID?

    1. Right-click .ipa file and select Show Package Contents

    2. Look for a file ending in .plist

    3. Open the located file with a text editor

    4. Locate the Bundle ID, often a key containing the string BundleID or BundleIdentifier

    5. Locate a string tag similar to com.companyname.Appname

    6. Rename the configuration file to an app-specific name and save
      Save it someplace you’ll remember, for example with AIQ assets.

Create iOS AISG

  1. Open Terminal

  2. Enter appium and press Enter

  3. Start AIQ services if not already running

  4. Log into AIQ and go to AI Scripting > Create AISG

  5. Click Mobile
    If Mobile is disabled, request an updated AIQ license

  6. Select iOS in the Platform box

  7. Select Bundle Id in the Source box

  8. Select Tags in the Scan Type box (SmartTags not yet supported for Mobile)

  9. Confirm Visual Hints are enabled

  10. Click Browse in the Appium Servers box

  11. Select the Appium Server Simulator description file created earlier in the setup

  12. Click Next

  13. Proceed with the AISG creation as you would with any other AISG

    1. Enter a name in Execution Name box

    2. Click Load a Dataset from CSV file and check the file in the list or check Default and enter variables and values

    3. Click Create

  14. The Simulator launches, starts the Application and begins walking through the Application

  15. As Inputs Found updates, map any Custom Actions until reach the desired end point in the Application

  16. Download scripts in JS format (DS not yet supported for Mobile) to run in JS Edit & Play or in a Scenario

Notes

Last updated: July 05, 2023

If you have any feedback on this topic, please contact us at documentation@appvance.ai

AWS Device Farm Mobile Testing

What Is AWS Device Farm?

Device Farm is an app testing service that enables you to test and interact with your Android, iOS, and Web apps on real, physical phones and tablets that are hosted by Amazon Web Services (AWS). There are two main ways to use Device Farm:

Automated App Testing

Device Farm allows you to upload your tests or use built-in, script-free compatibility tests. Because testing is automatically performed in parallel, tests on multiple devices begin in minutes.

A test report containing high-level results, low-level logs, pixel-to-pixel screenshots, and performance data is updated as tests are completed.

Device Farm supports testing of native and hybrid Android, iOS, and Fire OS apps, including those created with PhoneGap, Titanium, Xamarin, Unity, and other frameworks. It supports remote access to Android apps for interactive testing.

Supported Test Types and Built-in Tests

Device Farm currently provides support for the following test types:

For Android:

For iOS:

For Web Apps:

If you do not have your tests, you can use a built-in fuzz test. For more information, see Built-in: Fuzz (Android and iOS).

Remote Access Interaction

Remote access allows you to swipe, gesture, and interact with a device through your web browser in real-time. There are several situations where real-time interaction with a device is useful. For example, customer service representatives can guide customers through how to use or set up their devices. They can also walk customers through how to use apps running on a specific device. You can install apps on a device running in a remote-access session and then reproduce customer problems or reported bugs.

During a remote access session, Device Farm collects details about actions that take place as you interact with the device. Logs with these details and video capture of the session are produced at the end of the session for your review.

Initially, a limited number of Android and Fire OS devices are supported for remote access. However, the list of devices will grow during the beta period and as new devices enter the market.

Test Types in AWS Device Farm

AWS Device Farm provides many different built-in and custom test types for Android, iOS, and Web applications. Built-in tests enable you to test your apps without writing scripts. Custom tests allow you to test specific flows and business logic within your app. For more information, see Working with Test Types in AWS Device Farm.

Android Test Types

Device Farm provides the following built-in and custom test types for Android devices.

iOS Test Types

Device Farm provides the following built-in and custom test types for iOS devices.

Web Application Test Types

Device Farm provides the following custom test types for Web applications.

Working with AWS Device Farm

  1. Log in to the AWS console using valid credentials and the user should be able to see the Home page of AWS as shown below

  2. Click Device Farm

  3. The user would be navigated to the Projects page as shown below

  4. Click New Project

  5. Enter the Project Name and click Create Project and the user will be navigated to the Run page

  6. Now User has 2 options to choose from

Automated Tests

Step by step instructions on how to run automated tests in Device Farm

  1. Click create a new run

  2. User will be directed to a page to select either Native application or Web Application

  3. Select Native application and upload the APK or IPA file depending on the OS

  4. The user will upload the file

    Device farm will give us details about the package and the activity name. It also gives information on the Target SDK, Version code, and Version name.

    The user clicks on Next Step

  5. The user will be presented with Configure page where the user has to select the test type

    AWS provides 2 built-in options for testing i.e Explorer and Fuzz. Rest needs to be developed by the User.

    I will be selecting the Explorer option to test the application. Once that is selected click the Next step

  6. The user will be navigated to the Select Devices page

    This page will inform the user of the device which is compatible with the apk file or ipa file. Users can also create their device pool using the “Create a new device Pool” option

    Click Next

  7. The user now will be presented to the Device state page

    User can change settings like wifi, Blue-tooth, etc.

    Click Next

  8. Review and start the Run page

    The user has to select the minutes carefully since if the time given by the user is less than the actual run then only partial results will be available to the user

    Once the above setting is done user clicks on confirm and runs the button

  9. The user will be presented to the Run page with a scheduled test in Progress

    Once the user clicks on the completed test, it will be navigated to the results page

    Where the user can check the video recording, Suites that were run, screenshots, and also the logs needed for debugging.

Remote Access

This feature allows the user to interact with the actual device which is launched in AWS

Steps to Start a new session are given below

  1. Click Start new session button on the Remote access page. Users will be presented with a page to select the device name, Platform, and OS

  2. Select the device and click the “Confirm and Start Run” button

  3. User will be presented with a page to indicate to the user that the device is being initialized in the back-end

  4. Device will be launched and users can perform actions as they would on a physical device

Last updated: February 16, 2024

If you have any feedback on this topic, please contact us at documentation@appvance.ai

Fallback Accessors for Mobile Testing

Fallback accessors help mobile tests continue to identify controls when the primary locator is unstable. Use them carefully: a fallback should target the same intended element, not merely a similar visible control.

When to use fallbacks

Validation checklist

  1. Confirm the primary and fallback accessors identify the same business control.
  2. Test on the target device types, orientations, and OS versions.
  3. Prefer accessibility labels, stable resource IDs, and meaningful text over coordinates.
  4. Document why the fallback exists and when it should be reviewed.

Last updated: October 6, 2026

Mobile Record From Here

The Record from Here option is available in the Mobile Designer. Record From Here is a debugging option that you can use to add more steps to existing test scripts.

This option was added in the AIQ 4.9.3 release. Previously, this option was only available in the Web Designer IDE.

To use the Record from Here option:

  1. Open a test script.

  2. Select a step within the script.

  3. Right-click and select Record From Here.

  4. Select the browser.

  5. The script will playback up to this point, and you will be able to continue to record adding additional steps into your scripts.

Last updated: July 17, 2023

If you have any feedback on this topic, please contact us at documentation@appvance.ai

Use Image Injection in AIQ Mobile Testing

Use Image Injection in AIQ Mobile Testing

Image injection lets a mobile test provide a controlled image to the application under test when the scenario needs repeatable camera, upload, or visual-input behavior. Use controlled test images and avoid customer-sensitive content.

When to use image injection

Validation workflow

  1. Select a small set of approved test images with known expected results.
  2. Configure the mobile environment so the application receives the injected image.
  3. Add assertions for the screen, uploaded file, extracted text, or downstream record.
  4. Run the test on the required device profile and review evidence.

Data-safety note: Do not inject real customer documents, IDs, or private images unless the customer has explicitly approved that test data.

Last updated: October 8, 2026

Use Visual Accessors for Mobile Testing

Last reviewed: September 30, 2026

Use this article when mobile tests need visual matching because a stable DOM, accessibility ID, or native locator is not available.

What changed in this article

Validation workflow

  1. Try a stable native, accessibility, or DOM locator first when the app exposes one.
  2. Use a tightly cropped visual accessor only for the element region that must be matched.
  3. Replay on the target device profile and confirm the match survives expected resolution, orientation, and theme variations.

Review note: This page now explains when visual accessors help mobile testing and how to reduce false positives.

Last updated: September 30, 2026

If you have feedback on this topic, contact documentation@appvance.ai.

Mobile Self-Healing Support in AIQ

Last reviewed: September 24, 2026

Use mobile self-healing to improve locator resilience when supported mobile elements change in predictable ways.

What changed in this article

Validation workflow

  1. Run the mobile scenario and identify locator failures that are candidates for healing.
  2. Enable or review self-healing behavior for the affected steps.
  3. Replay on the target device matrix and confirm the healed step still validates the intended UI element.

Review note: Aligned the article with current AIQ self-healing language and added mobile-specific validation details.

Last updated: September 24, 2026

If you have feedback on this topic, contact documentation@appvance.ai.

Sample Mobile Testing Scenarios

Sample Mobile Testing Scenarios

Use sample mobile scenarios as starting points for learning AIQ mobile testing patterns. Review and adapt each sample before using it in a maintained test suite.

How to use samples

  1. Confirm the sample applies to the AIQ release, device type, and application under test.
  2. Replace demo data, accounts, and environment-specific values with approved test data.
  3. Update locators and waits so they match the current application behavior.
  4. Run a short validation execution and review output before adding the scenario to a suite.

Maintenance notes

Last updated: September 18, 2026

Generate Mobile Traffic for Performance Testing

Generate Mobile Traffic for Performance Testing

Use mobile traffic generation when performance testing must include requests produced from a mobile application or mobile browser flow. Keep the setup controlled so the captured traffic represents the target use case and can be repeated.

Before you start

  1. Capture the mobile traffic required for the scenario.
  2. Review and clean the captured requests before scaling the run.
  3. Parameterize dynamic values and test data.
  4. Run a small validation execution, then increase load in controlled stages.

Last updated: September 18, 2026

Test Mobile Responsiveness in a Browser

Test Mobile Responsiveness in a Browser

Use browser-based mobile responsiveness testing to validate layout behavior at common mobile viewport sizes. This is useful for responsive web applications, but it does not replace testing on real mobile devices when device-specific behavior matters.

What to validate

Good practices

  1. Test the smallest supported viewport first.
  2. Validate at least one common phone and one tablet breakpoint when applicable.
  3. Confirm critical flows on a real device or emulator before release decisions.

Last updated: September 18, 2026

Mobile Apps - Processing Requests

Android Emulator and Physical Device:

This is regarding capturing all the HTTPS requests of the application and finding issues (slow requests and failing requests) from our AI technology, we need help from the dev team in compiling the application with the appvance certificate and Network security configuration XML file to be added to App's manifest XML File.

Reason for this: (We are bound to follow Android's security policies)

Since the introduction of Nougat (API 24) to Android, a number of changes were introduced to how Android handles trusted certificate authorities (CAs). Before, one only needs to install the self-signed SSL .cer file in the emulator/device Security Settings. Then the app will just simply be able to access your secure endpoints (HTTPS) using the global device settings.

The complete blog is here

There are only 3 steps to follow - For the first one, click here to download the pem file, the dev team should do the next 2 steps and send us the apk file.

IOS Simulator and Real Devices:

For Simulator, .app is required.

For Real Device testing, .ipa is required.

We will need access to TestFlight or other invitations in order to test the builds if the dev team compiles the app and uploads them on TestFlight to get the different app build versions to download and install/test the versions.

For Real Devices testing, the app should comply with the UDID of the device that will be used for testing to listen to all the requests and responses.

For instance, if we need to test on iPhones 8, 10, and 11, the UDIDs of those devices should be registered and complied with for us to download and install on those physical devices.

The reason for that is due to Apple’s policies on app distribution for testing, according to the below

Apple Help Xcode

Developer Apple Xcode

Is it compulsory to have UDIDs registered?

if we want to provide our device UDIDs and trust the client (even though we can’t think of any possible harm)

but we believe that the simplest and easiest way to deal with this (in order to avoid having the client register our iPhone’s UDID) is to use TestFlight

The customer simply provides us the link (hopefully it does not expire) and we can test their app without them having to register our UDIDs.

Last updated: June 02, 2023

If you have any feedback on this topic, please contact us at documentation@appvance.ai

Use Drag Gestures in Mobile Tests

Use this article when a mobile test needs to perform a drag gesture on a device or mobile browser viewport.

What changed in this article

Validation workflow

  1. Confirm the target element, device profile, orientation, and expected start/end position.
  2. Run the drag with conservative timing and verify the application state after the gesture.
  3. Replay on the same target profile and adjust only after reviewing screenshots or video evidence.

Review note: This page now documents drag as a mobile gesture with reproducibility checks.

Last updated: October 5, 2026

If you have feedback on this topic, contact documentation@appvance.ai.

Use Pinch Zoom Gestures in Mobile Tests

Use this article when a mobile test needs to zoom in or zoom out using a pinch gesture in a supported mobile workflow.

What changed in this article

Validation workflow

  1. Confirm the application supports pinch zoom and define the expected zoom result.
  2. Run the gesture on the target device profile and capture evidence before and after zooming.
  3. Validate that the next step uses stable locators or visual evidence that still works at the new zoom level.

Review note: This page now focuses on repeatable mobile zoom behavior.

Last updated: October 5, 2026

If you have feedback on this topic, contact documentation@appvance.ai.

Geo Location

You can use Geo Location for iOS and Android phones with Browser Stack, SauceLabs, and On Premise testing. The Geo Location format is latitude and longitude in decimal format.

Last updated: September 17, 2024

If you have any feedback on this topic, please contact us at documentation@appvance.ai