Hi friends,
initially, In this blog, we learn about “why we need Desired Capabilities in Appium“, so as we discussed earlier, Appium is a tool used for mobile testing. It also required a connection between mobile and Appium server that things which help to make a proper bond in between are “Desire Capabilities.”

Appium tool is an open-source, cross-platform automation testing tool, and therefore the tool focuses on both Android and iOS apps. After that, It is only bound to the mobile application testing field. Appium server is scripted in Node.js and fits with leading client libraries like Java, Python, Ruby, PHP, and others.
Appium does not depend on mobile device operating systems because it has a frame that turns the Selenium web driver commands to UIAutomator commands for Android and iOS respectively.it only depends on the device type rather than its OS.
Desired Capabilities
Desired Capabilities, also known as JSON Wire Protocol, refer to the mixture of key-value pairs encoded in a JSON object. Basically, JSON Wire Protocol is the mechanism used for communicating between client and server. It is developed by web driver developers but According to them, the protocol is a bunch of standardized endpoints that are exposed to the client using a RESTful API. This also allows the web driver to build a connection with a server and a client to perform automation.
Appium Architecture
Initially, Desired Capabilities helped us to configure the Appium server. It also gives the standards by which we want to run our automation script. Appium server also receives HTTP requests from the client libraries in JSON format. The requests are then handled in different ways, depending on the platform on which it is running on.
For example, we can request the environment (emulator or real-device), which version of the operating system to run the test on, and more. Desired Capabilities are key/value pairs encoded in JSON format and are sent to the Appium Server by the Appium client when a new automation session is requested.
It follows the Client-Server Architecture. There are 3 parts included in it:
- Appium Client
- Appium Server
- End device



There are many capabilities that Appium supports; accordingly, we can categorize the Capabilities into three parts:
1. General Capabilities
CAPABILITY | DESCRIPTION | VALUES |
---|---|---|
automationName | Which automation engine to use | Appium (default), or UiAutomator2 , Espresso , or UiAutomator1 for Android, or XCUITest or Instruments for iOS, |
platformName | Which mobile OS platform to use | iOS , Android , or FirefoxOS |
platformVersion | Mobile OS version | e.g., 7.1 , 4.4 |
deviceName | set of mobile device or emulator to use | iPhone Simulator , iPad Simulator , iPhone Retina 4-inch , Android Emulator , Galaxy S4 , etc. |
app | use HTTP and also use the local path where an app file is present or add a location like /home/knoldus/Downloads | /abs/path/to/ my.apk or http://myapp.com/app.ipa |
browserName | Name of a mobile web browser to automate. also, use a blank string when automating the app instead. | ‘Safari’ for iOS and ‘Chrome,’ ‘Chromium,’ or ‘Browser’ for Android |
udid | Unique device identifier of the connected physical device | e.g. 1ae203187fc012g |
noReset | Don’t reset the app state before this session. See here for more details. | true , false |
fullReset | Perform a complete reset. See here for more details. | true , false |
language | Language to set for iOS (XCUITest driver only) and Android. | e.g. fr |
eventTimings | Enable or disable the reporting of the timings for various Appium-internal events (e.g., the start and end of each command, etc.). Defaults to false . To enable, use true . The timings are then described as property in response to querying the current session. | e.g., true |
orientation | (Sim/Emu-only) start in a specific orientation | LANDSCAPE or PORTRAIT |
newCommandTimeout | How long (in seconds) Appium will wait for a new command from the client before assuming the client quit and ending the session | e.g. 60 |
clearSystemFiles | Delete any created files at the end of a session. Default to false . | true , false |
printPageSourceOnFindFailure | When a find operation fails, print the current page source. Defaults to false . | e.g., true |
As Appium supports both Android and iOS, There are various capabilities for both. However, most of the capabilities remain common to both platforms.
initially required settings to build a connection from a Device
2. Android Desired Capabilities–
{
"platformName": "Android",
"platformVersion": "8",
"app": "/Users/knoldus/Downloads/sample.apk",
"deviceName": "Realme 8"
"automationName": "UiAutomator2"
"noRest": "True"
}
Android-only Capabilities
Initially, When we are performing Android app automation, there are a bunch of Android-specific capabilities that can be used to set the session android application execution, sometimes involving multiple packages and activities.
appActivity (Android) | The name of the Android activity to be launched, displayed as the Launch activity in the app details card. |
appPackage (Android) | The set name that identifies the app, displayed as Package ID in the app details card. |
3. iOS Desired Capabilities-
{
"platformName": "iOS",
"platformVersion": "11.4.1",
"app": "/path/to/.ipa/file",
"deviceName": "iPhone13 pro ",
"udid": "bea36e2b0262ae4b77bd3463bd462922ee935d24"
"automationName": "XCUITest"
"autoAcceptAlerts": "True"
}
iOS-only Capabilities
For iOS-based, we have some common and some which are only specified only for the iOS system because iOS types are more advanced in relating to Android; therefore, we use some Desired Capabilities like calendarFormat, bundleId, and launchTimeout
bundleId (iOS) | A unique identifier, the Bundle ID of the app, is displayed as Package ID in the app details card. For example, “com.hpe.advantage”, |
Important capabilities :
Reset strategies
noReset | fullReset | RESULT ON ANDROID | RESULT ON IOS |
true | true | Error: The ‘noReset’ and ‘fullReset’ capabilities are mutually exclusive, but they do not set true at a time. | Error: The ‘noReset’ and ‘fullReset’ capabilities are mutually exclusive but they do not set true at a time. |
true | false | First, do not stop the app, do not clear app data, and do not uninstall the app. | Do not kill or shut down the Simulator after the test. Start tests running on whichever Simulator is running or device is plugged in. |
false | true | it Stops the app, precise app data, and uninstall the app after the test. | Uninstall app after real device test, destroy Simulator after sim test. |
false | false | initially Stop and clear app data after the test. Do not uninstall the app. | Shut down the Simulator after the test. then Do not kill the Simulator. Do not uninstall the app from an actual device. |
Where we use Desired Capabilities
we use DesireCapabilities when we create the session through-
- Appium Inspector
- IntelliJ IDEA or Eclipse IDE
1.Creating Desired Capabilities in Appium Inspector
Appium Desktop is an open-source app for Mac, Windows, and Linux also; therefore, it allows you to use Appium Server in an intuitive and simple Graphical UI compared to the command line.
You can install it from here – Appium Desktop
Enter the above given Desired Capabilities in the Appium Inspector during the Session Configuration window as shown below. Therefore it has a saved capability choice which keeps the enter capabilities in our memory.



2. Creating Desired Capabilities in IntelliJ IDEA or Eclipse IDE
IntelliJ IDEA provides a complete feature set including tools and integrations with the most important modern technologies and frameworks for enterprise and web development with Java, Scala, Groovy, and other languages.
DesiredCapabilities is a predefined library, and also for using it, you need to import:
before that, we need to add dependency in our IDE – Linked language like in our case we use java, so need to set the dependency related to java,
import org.openqa.selenium.remote.DesiredCapabilities;
package appiumtest;
import io.appium.java_client.android.AndroidDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.remote.DesiredCapabilities;
import java.net.MalformedURLException;
import java.net.URL;
public class demo1 {
public static void main(String[] args) throws MalformedURLException {
DesiredCapabilities cap = new DesiredCapabilities();
cap.setCapability("AUTOMATION_NAME"," UIAutomator2");
cap.setCapability("PLATFORM_NAME","Android");
cap.setCapability("PLATFORM_VERSION","8.0");
cap.setCapability("DEVICE_NAME","8_Fold-out_API_Sv2");
cap.setCapability("NO_REST","false");
cap.setCapability("UDID","emulator-5554");
cap.setCapability("allowTestPackages","true");
//cap.setCapability("APP","/home/knoldus/Downloads/id.dana-2.6.0-APK4Fun.com.apk");
URL url= new URL("http://127.0.0.1:4723/wd/hub");
AndroidDriver<WebElement> driver=new AndroidDriver<WebElement>(url,cap);
driver.installApp("/home/knoldus/Downloads/");
System.out.println("Application started........");
}
}
That’s all for this blog, I Hope so learned about DesiredCapabilities, and in the next blog, we will learn more about appium, so stay tuned.
Thank you!!
References
https://appium.io/docs/en/writing-running-appium/caps/
https://www.browserstack.com/guide/desired-capabilities-in-appium