A Complete Tutorial to Appium Capabilities for Mobile Automation

Wasiq Bhamla

Posted On: July 28, 2023

view count153787 Views

Read time32 Min Read

Capabilities are a set of parameters that describes the device on which the Appium test should run, along with the application to be used for testing. These capabilities must be provided to the Appium Server while creating the session. With these capabilities, the Appium Server parses them and creates the session with the target device described in the capabilities, and installs or launches the target application on the device before our test starts executing.

Before we go into more detail with capabilities, let’s first understand Appium. Appium is an open-source mobile application testing framework and a complete ecosystem to help automate Android and iOS applications categorized across different mobile-based applications, like Native, Web, and Hybrid. It also supports automating Smart TV and Windows and macOS-based desktop applications.

Appium consists of two core components. The first is the Appium Server command line library, a NodeJS-based library that completely manages the Appium session created with the device. The second component is the Appium Client, which is available in multiple programming languages like Java, Python, JavaScript, etc. The client is responsible for communicating with the Appium Server and providing it with instructions about how to communicate with the application on the target device and test it.

Capabilities are used with these Appium Clients, which consume the capabilities provided to them and pass on these capabilities to the Appium Server, which in turn understands them and starts the mobile device session based on these capabilities.

In addition to leveraging Appium’s capabilities for interactions and validations, integrating Appium Visual Testing allows you to extend your testing horizon to include visual regressions. By automatically capturing and comparing UI screenshots between baseline and current versions, Appium Visual Testing helps identify even the subtlest visual discrepancies that might impact user satisfaction. This comprehensive approach not only ensures that your app functions as intended but also maintains its visual integrity across iterations.

In this blog on Appium Capabilities, we will be using Appium 2.0. To understand what changes Appium 2.0 brings in from Appium 1.x, it has decoupled Appium drivers from its command line tool. Earlier, it used to install all the available drivers when you installed the Appium command line tool. But with Appium 2.0, only the command line tool will be installed, while you can install only those drivers you want to use.

If you are using Appium 1.x and want to learn more about Appium 2.x or even switch to it, you can go through this Appium 2 migration guide.

In this tutorial on Appium Capabilities, we will cover different types of capabilities for Android and iOS platforms:

  • Common Appium capabilities, which are common irrespective of the target platform.
  • Platform-specific Appium capabilities, which are platform-specific, like Android has its own set of capabilities, and iOS has its own.
  • Driver-specific Appium capabilities, which are driver-specific, like the UiAutomator2 driver will have different capabilities than the Espresso driver.
  • Cloud platform-specific Appium capabilities, which are cloud provider specific and will differ from one cloud provider to another.

Appium Client libraries for different languages have different options classes created, which helps set many of these capabilities directly by exposing descriptive methods representing the corresponding capability name. So most of the time, you will call the respective method and pass the required value for the capability directly to that method. Once all the Appium capabilities are set, you will pass the options object instance to the corresponding driver class while creating the driver instance.

Common Appium Capabilities

The common capabilities are the ones that can be used for any platform you are automating with Appium. Let’s see the commonly used Appium capabilities irrespective of your working platform.

Note: While looking into these Appium capabilities, we will use the UiAutomator2Options class for examples of how to set these capabilities in the test. However, when you work on any particular platform, you will use the corresponding options class depending on your working platform.

platformName

In this capability, you will give the target platform name, which can be Android or iOS, depending on which platform is being automated. This capability is mandatory and must be provided to Appium.

If you use any of the available option classes and initialize it, this capability will be automatically set under the hood along with the automationName capability, so you don’t need to set it explicitly.

Following is the table which lists all the option classes along with their corresponding platform and automation name values which are automatically set when you use the option class:

Option class Platform Name Automation Name
UiAutomator2Options Android UiAutomator2
EspressoOptions Android Espresso
XCUITestOptions iOS XCUITest
Mac2Options Mac Mac2
WindowsOptions Windows Windows

For example, in the following code snippet, when we initialize the UiAutomator2Options options class, the platformName, and appium:automationName capabilities will get set to Android and UiAutomator2 respectively.

appium:automationName

This capability instructs Appium which Appium driver it must use to automate the application. It is a mandatory capability and must be set to run the tests. This capability is automatically set along with platformName when you use any available option classes, as explained earlier.

appium:platformVersion

This capability holds the target platform version number. It is an optional capability. If provided, it will help Appium narrow the search for the correct device. Check out the following code snippet on how to set the platform version capability using the option class:

For example, in the case of Android, you can mention any Android version you want to automate, like 12 or 11. In the case of iOS, you can mention the exact version, like 16.2.

browserName

If you want to automate a web application, you can use this capability to set on which browser you want to test that web application. If you use this capability, you can avoid using appium:app capability.

Info Note

Test your websites using Appium across 3000+ mobile browsers. Try LambdaTest Today!

appium:app

If you want to automate a native or a hybrid application, you can use this capability to set the path to the *.apk file on your machine for Android, *.ipa file path for iOS real device or *.app.zip / *.app file path for iOS simulator.

appium:deviceName

This capability is where you would give the device name on which you will be testing your application. This capability is not used internally for Android. However, it is used to find the target device in the case of iOS. So you must make sure you give the correct device name for iOS.

For example, you may give the iPhone 14 Pro device name for the iOS device.

appium:noReset

If this capability is set with the value as true, it will indicate the driver to skip its clean-up and reset logic from being applied at the start of the session. By default, the value is set as false.

appium:fullReset

If this capability is set with the value as true, it will instruct the Appium Server to do a complete reset of the device by deleting whatever temporary data which was created due to the previous executions including the applications which were installed before along with cleaning up any previous logs which are there on the device.

Full reset does not mean that Appium will simply wipe out the complete data of the device. It will only delete the files created by Appium when the test is executed. This ensures maximum environmental reproductivity. By default, the value is set as false.

appium:eventTimings

If this capability is set as true, it will instruct Appium to collect all the event timings each event takes to execute. By default, the value is set as false.

When this capability is enabled, you can get details of all the events and commands executed by Appium, along with the timings each of those events and commands took to execute.

Once this capability is enabled, you can get event details using the following code example:

appium:printPageSourceOnFindFailure

If the capability is set as true, it will instruct to print the complete page source when Appium fails to find any element. By default, the value is set as false.

appium:udid (optional, default: null)

This capability takes in the unique device ID of the target device on which you will be executing your test. For Android, you can get the UDID of the device by running adb devices -l on your terminal, as shown below:

shown

For iOS, you can get it from Xcode > Windows > Devices and Simulators > Simulators (see the reference screenshot below).

automatically

This capability is optional. If not provided, it will automatically find the device matching other Appium capabilities you have provided. But this capability must be provided if there is more than one real device with the same iOS versions connected to the machine. Appium will try finding the particular device matching the provided unique ID.

appium:settings[ < setting-name > ]

With this capability, you can apply any of the available Appium settings which you would otherwise use driver.setSetting (“settingName”, “settingValue”); after the session is started. Using this capability, you can replace the < setting-name > with the actual setting name and assign the value of that setting.

You can get all the list of supported settings from the following driver documentations:

appium:enforceAppInstall

If this capability is set to true, then the application under test is always reinstalled even if a newer version of it already exists on the device under test. This is set to false by default.

appium:language

This capability sets the application language based on the format of the ISO-639 code for alpha-2 or alpha-3 language code. To illustrate, when configuring the application language to French, you should set the capability as “fr,” while for English, it will be “en.” The device’s system language will be utilized by default.

appium:locale

This capability sets the application language based on the format of ISO-3166 two-letter country code or three-digit country code. By default, the device system locale will be used. For example, if you want to set the locale to France, you must set the value as FR or 250.

appium:otherApps

You can provide a comma-separated list of one or more applications that you want to install before you run your test because they are the dependent applications on which the application under test relies on.

appium:isHeadless

If you want to run your test in a headless mode on any virtual device, whether it’s on Android Emulator or iOS Simulator, then you must set this capability as true. By default, this capability is set to false.

appium:skipLogCapture

If you want to enforce Appium to skip capturing the logs during the test execution, then you must set this capability as true. This would improve network performance. If this capability is enabled, then any log-related commands will not work. By default, this capability is set to false.

appium:newCommandTimeout

Maximum amount of time in seconds should Appium driver wait for a command from the client to get executed before assuming that the client is no longer active. By default, 60sec is set for this capability. This capability is not supported by the Android Espresso driver.

appium:mjpegServerPort

The number of the port the Appium server starts the MJPEG server on. If not provided, then the screenshots broadcasting service on the remote device does not get exposed to a local port (e.g., no adb port forwarding is happening). This capability is not supported by the Android Espresso driver. You can learn more about it through this blog on ADB commands.

Platform-Specific Appium Capabilities

Apart from the common capabilities seen earlier, some platform-specific Appium capabilities are common throughout that platform. Let’s check out all these capabilities for each of the platforms.

Following are Android-specific capabilities that are commonly supported irrespective of the driver you might be using whether UiAutomator2 or Espresso drivers.

appium:systemPort

This is the port number on which the corresponding Android driver listens. By default, any of the 8200-8299 free port numbers will be used. But if you want to execute your tests in parallel, you must ensure that you provide a unique systemPort number capability.

appium:skipServerInstallation

If you set this capability as true, then the driver will skip the server component installation on the device along with any related checks. This will help speed up the test execution only when you are sure your target device already has the correct server component installed.

In case you are running for the first on any device, you must keep this capability disabled to make sure all the required Appium server components get installed. By default, the value is set as false.

appium:appPackage

This capability will try to launch the application with the same package name as provided to the capability. If this capability is not provided, Appium will find the application package name from the appium:app capability.

appium:appActivity

Appium will try to launch the application activity which matches the provided capability. If not provided, Appium will automatically identify the main activity from the appium:app capability.

appium:appWaitActivity

The activity name for which Appium should wait till it gets launched. If not provided, then by default appium:appActivity value is used.

appium:appWaitPackage

The package name for which Appium should wait till it gets launched. If not provided, then by default appium:appPackage value is used.

appium:appWaitDuration

The wait timeout in milliseconds for which Appium should wait until the application under test gets launched. By default, 20000 ms is used.

appium:androidInstallTimeout

This is the maximum amount of time Appium will wait till the application under test is installed on the device. By default, Appium will wait till 90000 ms.

appium:autoGrantPermissions

If this capability is set to true, then Appium will automatically grant any permissions which the application under test may request when it is first installed and launched, else, you will see the permissions pop-up whenever the application under test starts for the first time. By default, this is set as false.

appium:uninstallOtherPackages

You can provide a comma-separated list of one or more applications you want to uninstall before you run your test on that target device.

appium:allowTestPackages

If you set this capability to true, then it would be possible to use packages built with the test flag for automated testing, which means it adds -t flag to the adb install command. This is set as false by default.

appium:remoteAppsCacheLimit

This capability sets the maximum amount of application packages to be cached on the device under test. This is needed for devices that don’t support streamed installs, for example, Android 7 and below, because adb must push app packages to the device first to install them, which takes some time. Setting this capability to 0 disables app caching, which is not required for Android 8 and above because that supports streamed installation. By default, this capability is set as 10.

appium:adbPort

This capability sets the port number on which ADB is running. By default, Appium will listen on the 5037 port number.

appium:remoteAdbHost

This is the host address on which ADB will be running.

appium:adbExecTimeout

This will be the maximum amount of time in milliseconds Appium will wait for a single ADB command to get executed. By default, this capability value is set as 20000 ms.

appium:clearDeviceLogsOnStart

If this capability is set as true, then the corresponding Appium driver will clear all the logs from the device buffer before the test gets executed.

appium:suppressKillServer

If this capability is true, then the Appium driver will not explicitly kill the ADB server. This capability is useful to be enabled when you have connected your target device via WiFi. By default, this capability is set as false.

appium:avd

You can set the name of the Android emulator to run the test on. The names of currently created emulators could be listed using the emulator -list-avds command. If the emulator with the given name is not running, it will be launched on automated session startup.

appium:avdLaunchTimeout

You can set the maximum amount of time in milliseconds Appium should wait for the Android Emulator to launch. By default, the capability is set to 60000 ms.

appium:avdReadyTimeout

You can set the maximum amount of time in milliseconds Appium should wait for the Android Emulator to be fully loaded and ready for running the tests. By default, the capability is set to 60000 ms.

appium:avdArgs

You can pass the Android emulator arguments to this capability. Appium will use these arguments while starting the Emulator.

appium:chromedriverPort

This capability sets the port number on which Appium will listen for Chrome driver communications. By default, this capability is unset.

appium:chromedriverExecutableDir

This capability will contain a full path to the folder where the downloaded Chrome driver executable is stored when Appium automatically downloads the driver.

appium:chromedriverExecutable

This capability will contain the complete path to the Chrome driver executable.

appium:chromedriverArgs

You can provide the Chrome driver-specific arguments by using this capability which Appium will use when launching the browser on the device. This capability is an array of Chrome driver arguments.

appium:chromeOptions

This capability takes a map of Chrome options to customize the Chrome driver. Check out this documentation for a complete list of supported Chrome options.

appium:skipUnlock

When this capability is set to true, then Appium will not check if the device screen is currently locked. By default, it’s set as false, which means, Appium checks if the device is locked and tries to unlock the device if it’s locked.

appium:unlockType

You can provide the unlock type your device uses to unlock. This value can be any one of the following:

  • pin: It is a numeric pin code
  • password: It is an alphanumeric password
  • pattern: It is a finger gesture pattern
  • fingerprint: It is a fingerprint biometric
  • pinWithKeyEvent: It is a numeric pin code which is entered using a key event

appium:unlockKey

You can set the unlock key which Appium can use to unlock the device with.

appium:unlockSuccessTimeout

This is the maximum time in milliseconds Appium will wait for the device under test to get unlocked. By default, this value is set as 2000 ms.

appium:disableWindowAnimation

If this capability is set to true, the device window animation will be disabled. By default, this capability is set as false.

appium:noSign

When this capability is set to true, Appium will skip signing the application under test with the default Appium debug signature. You can disable the application signing if you want to test your application as is without any modification. By default, this capability is set as true.

Following are the capabilities specific to the iOS platform.

appium:updatedWDABundleId

You can provide a bundle id to this capability, which Appium will use to update WDA before building and launching it on real devices. This bundle id must be associated with a valid provisioning profile. For example, you can set its value as io.appium.WebDriverAgentRunner.

appium:xcodeOrgId

This capability will take the Apple developer team identifier, which is a 10-character long string. This capability must be used in conjunction with appium:xcodeSigningId to take effect.

appium:xcodeSigningId

This capability is the string representing a signing certificate. It must be used in conjunction with appium:xcodeOrgId. This is usually just iPhone Developer, so the default (if not provided) is iPhone Developer.

appium:webDriverAgentUrl

If you provide this capability a value, then Appium will connect to an existing WebDriverAgent instance at this URL instead of starting a new one. By default, http://localhost:8100 is used.

appium:useNewWDA

If this capability is set to true, Appium will uninstall any existing WebDriverAgent application installed on the device and build and install the new instance of WDA.

For real devices, it is required for the WebDriverAgent client to run for as long as possible without reinstalling/restarting to avoid any issues. The false value, the default behavior, will try to detect the currently running WDA listener executed by previous testing sessions and reuse it if possible, which is highly recommended for real device testing and to speed up suites of multiple tests in general.

appium:wdaLaunchTimeout

This capability takes time, in milliseconds, which Appium will wait until WebDriverAgent is launched. By default, Appium uses 60000 ms.

appium:wdaConnectionTimeout

This is the timeout in milliseconds which Appium will wait for the response from WebDriverAgent to respond. By default, 240000 ms is used.

appium:wdaStartupRetries

This is the number of times the Appium server will try to build and start up the WDA on the device before failing the test execution. By default, 2 is set for this capability.

appium:wdaStartupRetryInterval

This is the time interval between the retries for building and launching the WDA on the device in milliseconds. By default, 10000 ms is used.

appium:wdaLocalPort

If you specify this capability value, Appium will use it to forward traffic from Mac host to real iOS devices over USB. By default, the value is the same as the port number used by WDA on the device.

appium:usePrebuiltWDA

If this capability is set to true, then Appium will not build the WebDriverAgent. It will be your responsibility to build the WDA manually. This feature is available for XCode v8 or above. By default, this capability is set to false.

appium:waitForIdleTimeout

This capability takes in the time in seconds in a floating number to wait until the application under test is getting idle. Since XCTest requires the main thread to be idle for the next command to get executed. The WDA will not even start or freeze if the application under test is constantly hogging the main thread. By default, Appium will use 10 seconds.

appium:maxTypingFrequency

The maxing keystrokes for typing or clearing the text in the element. If your test fails due to incorrect typing, you can try changing this capability. By default, this capability is set to 60 keystrokes per minute.

appium:autoAcceptAlerts

This capability, when set to true, will instruct Appium to accept all the iOS alerts when they pop up automatically. This also includes all the privacy access permissions pop-ups. By default, this capability is set to false.

appium:autoDismissAlerts

This capability, when set to true, will instruct Appium to dismiss any iOS alerts when they pop up automatically. This also includes all the privacy access permissions pop-ups. By default, this capability is set to false.

Following is the example code snippet on how to disable this capability:

appium:connectHardwareKeyboard

If you set this capability to true, then Appium will connect with the hardware keyboard on the Simulator. By default, this capability is set as false.

appium:simulatorStartupTimeout

You can set the timeout value in milliseconds which Appium will wait for the simulator to start up completely. By default, this capability is set as 120000 ms.

appium:simulatorTracePointer

You can enable a pointer tracker on the simulator to see any touch or swipe gestures happening on the screen of the simulator by setting this capability to true. You must ensure that the simulator is shut down before applying this change, else this change will not reflect on the simulator. By default, this capability is set to false.

appium:permissions

You can provide any permissions your application under tests might need during your test execution. You must provide the value for this capability in the following format:

To check what service names you must use, then run this xcrun simctl privacy booted on your terminal to get the supported service names.

You must set the corresponding service value by providing yes, no, or unset as values to grant, revoke or reset its corresponding permissions.

For example, you can set this capability value as {“com.apple.yourapp”: {“calendar”: “YES”}} to provide calendar permissions to your application under test.

appium:launchWithIDB

You can prefer to use IDB to launch WebDriverAgentRunner instead of the Xcode build tool by setting this capability to true. This will help improve the startup time because the Xcode build will be skipped. By default, this capability is set to false.

appium:clearSystemFiles

If you set this capability as true, then Appium will clear all the temporary files created by XCTest during the test execution, including logs. By default, this value is set to false.

Driver-Specific Appium Capabilities

There are some capabilities in Appium specific to a particular driver type. Let’s check out all of these capabilities.

For Android, there are currently two drivers supported by Appium, these are UiAutomator2 and Espresso driver.

Following are the Appium capabilities specific to the UiAutomator2 driver:

appium:uiautomator2ServerLaunchTimeout

This is the maximum number of time in milliseconds Appium will wait for the UiAutomator2 server to launch on the device. By default, this capability is set as 30000 ms.

appium:uiautomator2ServerInstallTimeout

This is the maximum number of time in milliseconds Appium will wait for the UiAutomator2 server to be installed on the target device. By default, this capability is set as 20000 ms.

appium:uiautomator2ServerReadTimeout

This is the maximum number of time in milliseconds Appium will wait for HTTP response to come from the UiAutomator2 server which is installed on the target device. By default, this value is set as 240000 ms.

appium:skipDeviceInitialization

This capability, when set to true, then Appium will skip all the device checks and initialization steps. If you are sure that the initialization steps have already run properly before, then you can enable this capability to speed up the session creation step by skipping the device initialization step. By default, this value is set as false.

appium:autoLaunch

This capability, if set to false, will restrict Appium from launching the application under test when starting a new session on the device. By default, this capability is set as true.

Following are the Appium capabilities that are specific to the Espresso driver:

appium:espressoServerLaunchTimeout

This capability is the maximum time in milliseconds Appium will wait for the Espresso server to get launched on the device under test. By default, this value is set as 45000 ms.

appium:forceEspressoRebuild

This capability, when set to true, then Appium will rebuild the Espresso server .apk file every time the session is created. By default, this capability is set as false, which means Appium will only rebuild the Espresso server APK file when required or use the server APK from the cache.

appium:espressoBuildConfig

This capability would contain the full path of JSON config containing the Espresso config, or it can contain the JSON string itself with Espresso Build configs.

appium:showGradleLog

When this capability is set to true, then Appium server logs will also contain Espresso Gradle logs. By default, this capability is set to false.

Cloud-Specific Appium Capabilities

In today’s world, numerous cloud providers offer unique custom Appium capabilities that you must configure to run tests on devices hosted on their platforms. In this blog, we’ll focus on the LambdaTest cloud – an AI-powered test orchestration and execution platform that lets you perform mobile app testing using the Appium framework on a real device cloud. They provide a convenient Automation Capabilities Generator for generating all their supported capabilities, which can be customized per your needs.

Subscribe to the LambdaTest YouTube Channel and stay up to date with the latest tutorials around Selenium testing, Cypress testing, and more.

To get started with Appium for mobile automation, visit the documentation Appium testing on LambdaTest.

Let’s explore some of their frequently used Appium capabilities that will simplify running your mobile tests on their devices.

w3c

This capability, when set as true, indicates to LambdaTest that you want to use the W3C protocol for your test automation.

platformName

This capability will set the platform name on which your test will run. For example, Android when you want to run on an Android device.

deviceName

This capability will set the device name on which the test will get executed. For example, if you were to run your test on a Google Pixel device, you can set this capability as Pixel 6.

platformVersion

This capability will set the platform version on which you want to run your test. For example, if you want to run on the Android 12 platform, you can set this capability as 12.

app

This capability will set the LambdaTest application URL, which points to the application under the test you want to install on the target device. The format of the value for this capability is lt://< hash-id >.

project

This capability sets the project name, which categorizes the test session on the LambdaTest platform.

build

This capability sets the build name, which categorizes the test session on the LambdaTest platform under the project name.

name

This capability sets the test execution session name, which gets categorized under the project and build names that are set by the earlier capabilities.

devicelog

This capability, when set to true, will enable device-specific logs capturing, which you can view on the LamdaTest dashboard once the test execution is completed.

visual

This capability, when set to true, will capture screenshots on each step of the test execution, which you can view on the LambdaTest dashboard.

network

This capability, when set to true, will enable capturing network calls happening from the application under test, which you can view on the LambdaTest dashboard once the test execution has been completed.

video

This capability when set to true, will enable capturing video recording of your test execution which can be viewed on the dashboard once the test execution has completed.

deviceOrientation

This capability can be used to set the device orientation for the test session. Possible values which can be used for this capability are:

  • portrait
  • landscape

geoLocation

This capability can be used to set the geographical location of the device under test to whatever country in the world. You can provide ISO country code alpha 2 code. You can learn more about it through this blog on GPS Geolocation vs IP Geolocation.

location

This capability can be used to set the exact location of the device under test. You can provide the latitude and longitude to set the device location. You can learn more about it through this blog on Geolocation testing.

isRealMobile

You can set this capability to true if you want to run on a real cloud device.

Info Note

Test your mobile apps on real Android and iOS devices. Try LambdaTest Today!

autoGrantPermissions

You can set this capability to true, then it will automatically grant permissions to all the permissions required by the application under test.

autoAcceptAlerts

You can set this capability to true, then it will automatically accept the alert pop-ups which may occur in the application under test.

idleTimeout

You can set this capability to an integer to set the idle timeout in seconds. LambdaTest will wait for this idle timeout before canceling a test session if there is no activity happening in that session.

queueTimeout

You can set this capability to an integer to set the queue timeout in seconds. LambdaTest will wait for this idle timeout before canceling a test session in the queue but not getting executed until the timeout occurs.

language

You can set the language to any other language for the application under test. You can provide ISO language code of 2 char code.

locale

You can set the locale for the application under test.

Note: Boost your efficiency by ultimate guide of Appium Commands Cheat Sheet for Developers.

That’s a wrap!

I would like to thank you for reading here. I tried my best to cover all the useful capabilities you can use in your daily work while working with Appium.

I hope this blog on Appium capabilities helps you improve while performing Appium automation and gain more knowledge and confidence so you know exactly why you use a particular capability in your Appium test.

If you liked the blog on desired capabilities in Appium, share it with your friends so they can also benefit from it and know what capabilities Appium supports.

Info Note

We have compiled all Appium Interview Questions for you. Feel free to visit it. Check it out now!

Frequently Asked Questions (FAQs)

What are Appium capabilities?

Appium capabilities, also known as desired capabilities, are a set of key-value pairs that define various parameters and settings used to configure and customize the behavior of the Appium server and the mobile application during test automation. These capabilities act as instructions to the Appium server, specifying the device platform, automation-related settings, app information, and other configurations required to interact with the mobile application effectively.

What is an example of desired capabilities in Appium?

DesiredCapabilities empower users to manage the session requests with the server, enabling them to specify their preferences. For instance, if an iOS session is desired, the Capability “PlatformName = iOS” can be set, and for an Android session, the Capability “PlatformName = Android” can be configured.

Author Profile Author Profile Author Profile

Author’s Profile

Wasiq Bhamla

Wasiq is a Test Automation specialist having more than 15 years of experience in Manual and Automation testing. He has vast experience in automating Desktop, Web, API, Android, and iOS based applications. He is also an active open source contributor on GitHub, a freelancer, a mentor, and a blogger.

Blogs: 5



linkedintwitter

Test Your Web Or Mobile Apps On 3000+ Browsers

Signup for free