Understanding Appium Desired Capabilities

Appium Desired Capabilities help us to configure the Appium server and provide the criteria which we wish to use for running our automation script. 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.

In this article, we will take a deep dive into this feature. Previously, we introduced you to Appium Desired Capabilities. This is a core capability of Appium, and if you missed it, you should also go back and review.

Figure-1:Appium Architecture.

Desired capabilities is a predefined library and in order to use it you need to import:

Org.openqa.selenium.remote.DesiredCapabilities

As Appium supports both Android and iOS, There are separate capabilities for both. However most of the capabilities remain common to both platforms.

Android:

{
 "platformName": "Android",
 "platformVersion": "8.0",
 "app": "/Users/username/Downloads/sample.apk",
 "deviceName": "c4e3f3cda"
 "automationName": "UiAutomator2"
}

iOS:

{
 "platformName": "iOS",
 "platformVersion": "11.4.1",
 "app": "/path/to/.ipa/file",
 "deviceName": "John’s iPhone",
 "udid": "bea36e2b0262ae4b77bd3463bd462922ee935d24"
 "automationName": "XCUITest"
}

The above is the JSON representation. To use this in code, you can define the desired capabilities (for Android) as below:

DesiredCapabilities dc = new DesiredCapabilities();
dc.setCapability("platformName", "Android");
dc.setCapability("platformVersion", "8.0");
dc.setCapability("app", "/Users/test/Downloads/FirstAutomationTest/src/test/resources/DemoApp.apk");
dc.setCapability("deviceName", "c4e3f3cd");
dc.setCapability("automationName", "UiAutomator2");

In the above code snippet instead of defining capability name in a string you can use the Appium predefined interfaces such as MobileCapabilityType, IOSMobileCapabilityType and AndroidMobileCapabilityType to get capability names, so the above code snippet can be written in a better way:

DesiredCapabilities dc = new DesiredCapabilities();
dc.setCapability(MobileCapabilityType.PLATFORM_NAME, "Android");
dc.setCapability(MobileCapabilityType.PLATFORM_VERSION, "8.0");
dc.setCapability(MobileCapabilityType.APP, "/Users/test/Downloads/FirstAutomationTest/src/test/resources/DemoApp.apk");
dc.setCapability(MobileCapabilityType.DEVICE_NAME, "c4e3f3cd");
dc.setCapability(MobileCapabilityType.AUTOMATION_NAME, "UiAutomator2");

Appium Desired Capabilities for iOS and Android

We have many Appium desired capabilities at our disposal, depending on what we are trying to accomplish. However, there are specific capabilities we need to set based on what we are trying to test:

• Mobile Web Android.
• Mobile Web iOS.
• Mobile Native Android.
• Mobile Native iOS.

Mobile web – Android

If you want to automate the Chrome browser on Android device, then you need to use these Desired Capabilities.

DesiredCapabilities dc = new DesiredCapabilities();
dc.setCapability(MobileCapabilityType.PLATFORM_NAME, "Android");
dc.setCapability(MobileCapabilityType.PLATFORM_VERSION, "OS version of your test device/simulator");
dc.setCapability(MobileCapabilityType.DEVICE_NAME, "Name of your test device");
// This capability will open the Chrome browser instead of Native app.
dc.setCapability(MobileCapabilityType.BROWSER_NAME, MobileBrowserType.CHROME);
dc.setCapability(MobileCapabilityType.AUTOMATION_NAME, "UiAutomator2");

Mobile web – iOS

DesiredCapabilities dc = new DesiredCapabilities();
dc.setCapability(MobileCapabilityType.PLATFORM_NAME, "iOS");
dc.setCapability(MobileCapabilityType.PLATFORM_VERSION, "OS version of your test device/simulator");
dc.setCapability(MobileCapabilityType.DEVICE_NAME, "Name of your test device");
// This capability will open the Safari browser instead of Native app.
dc.setCapability(MobileCapabilityType.BROWSER_NAME, MobileBrowserType.SAFARI);
dc.setCapability(MobileCapabilityType.AUTOMATION_NAME, "XCUITest");
// If you are using Real iPhone device then you need to specify "udid" of device.
dc.setCapability("udid", "UDID of your test device");

Mobile native – Android

DesiredCapabilities dc = new DesiredCapabilities();
dc.setCapability(MobileCapabilityType.PLATFORM_NAME, "Android");
dc.setCapability(MobileCapabilityType.PLATFORM_VERSION, "OS version of your test device/simulator");
dc.setCapability(MobileCapabilityType.APP, "/path/to/.apk/file");
dc.setCapability(MobileCapabilityType.DEVICE_NAME, "Name of your test device");
dc.setCapability(MobileCapabilityType.AUTOMATION_NAME, "UiAutomator2");

Mobile native – iOS

DesiredCapabilities dc = new DesiredCapabilities();
dc.setCapability(MobileCapabilityType.PLATFORM_NAME, "iOS");
dc.setCapability(MobileCapabilityType.PLATFORM_VERSION, "OS version of your test device/simulator");
dc.setCapability(MobileCapabilityType.APP, "/path/to/.app or .ipa/file");
dc.setCapability(MobileCapabilityType.DEVICE_NAME, "Name of your test device");
dc.setCapability(MobileCapabilityType.AUTOMATION_NAME, "XCUITest");

There are many, many capabilities that Appium supports. We can categorize the capabilities into 3 parts:

• General Capabilities.
• iOS Capabilities.
• Android Capabilities.

While you clearly don’t need to memorize all of these, we do suggest you spend the time to familiarize yourself with these capabilities. As you use Appium more and more and continue to consult this list, you will eventually have a good sense of what capabilities are available to you.

General Capabilities

Capability	Description	Values
automationName	Which automation engine to use	Appium (default) or Selendroid or UiAutomator2 or Espresso for Android or XCUITest for iOS
platformName	Which mobile OS platform to use	iOS, Android, or Firefox OS
platformVersion	Mobile OS version	e.g., 7.1, 4.4
deviceName	The kind of mobile device or emulator to use	iPhone Simulator, iPad Simulator, iPhone Retina 4-inch, Android Emulator, Galaxy S4, etc…. On iOS, this should be one of the valid devices returned by instruments with instruments -s devices. On Android this capability is currently ignored, though it remains required.
app	The absolute local path or remote http URL to a .ipa file (IOS), .app folder (IOS Simulator) or .apk file (Android), or a .zip file containing one of these (for .app, the .app folder must be the root of the zip file). Appium will attempt to install this app binary on the appropriate device first. Note that this capability is not required for Android if you specify appPackage and appActivity capabilities (see below). Incompatible with browserName.	/abs/path/to/my.apk or https://myapp.com/app.ipa
browserName	Name of mobile web browser to automate. Should be an empty string if automating an app instead.	‘Safari’ for iOS and ‘Chrome’, ‘Chromium’, or ‘Browser’ for Android
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
language	(Sim/Emu-only) Language to set for the simulator / emulator. On Android, available only on API levels 22 and below	e.g. fr
locale	(Sim/Emu-only) Locale to set for the simulator / emulator.	e.g. fr_CA
udid	Unique device identifier of the connected physical device	e.g. 1ae203187fc012g
orientation	(Sim/Emu-only) start in a certain orientation	LANDSCAPE or PORTRAIT
autoWebview	Move directly into Webview context. Default false	true, false
noReset	Don’t reset app state before this session.	true, false
fullReset	Perform a complete reset.	true, false
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 reported as events property on response to querying the current session.	e.g., true
enablePerformanceLogging	(Web and webview only) Enable Chromedriver’s (on Android) or Safari’s (on iOS) performance logging (default false)	true, false
printPageSourceOnFindFailure	When a find operation fails, print the current page source. Defaults to false.	e.g., true

Android Capabilities

These capabilities are available only on Android-based drivers (like UiAutomator2 for example).

Capability	Description	Values
appActivity	Activity name for the Android activity you want to launch from your package. This often needs to be preceded by a . (e.g., .MainActivity instead of MainActivity). By default this capability is received from the package manifest (action: android.intent.action.MAIN , category: android.intent.category.LAUNCHER)	MainActivity, .Settings
appPackage	Java package of the Android app you want to run. By default this capability is received from the package manifest (@package attribute value)	com.example.android.myApp, com.android.settings
appWaitActivity	Activity name/names, comma separated, for the Android activity you want to wait for. By default the value of this capability is the same as for appActivity. You must set it to the very first focused application activity name in case it is different from the one which is set as appActivity if your capability has appActivity and appPackage.	SplashActivity, SplashActivity,OtherActivity, *, *.SplashActivity
appWaitPackage	Java package of the Androidapp you want to wait for. By default the value of this capability is the same as for appActivity	com.example.android.myApp, com.android.settings
appWaitDuration	Timeout in milliseconds used to wait for the appWaitActivity to launch (default 20000)	30000
deviceReadyTimeout	Timeout in seconds while waiting for device to become ready	5
androidCoverage	Fully qualified instrumentation class. Passed to -w in adb shell am instrument -e coverage true -w	com.my.Pkg/com.my.Pkg.instrumentation.MyInstrumentation
androidCoverageEndIntent	A broadcast action implemented by yourself which is used to dump coverage into file system. Passed to -a in adb shell am broadcast -a	com.example.pkg.END_EMMA
androidDeviceReadyTimeout	Timeout in seconds used to wait for a device to become ready after booting	e.g., 30
androidInstallTimeout	Timeout in milliseconds used to wait for an apk to install to the device. Defaults to 90000	e.g., 90000
androidInstallPath	The name of the directory on the device in which the apk will be push before install. Defaults to /data/local/tmp	e.g. /sdcard/Downloads/
adbPort	Port used to connect to the ADB server (default 5037)	5037
systemPort	systemPort used to connect to appium-uiautomator2-server, default is 8200 in general and selects one port from 8200 to 8299. When you run tests in parallel, you must adjust the port to avoid conflicts. Read for more details.	e.g., 8201
remoteAdbHost	Optional remote ADB server host	e.g.: 192.168.0.101
androidDeviceSocket	Devtools socket name. Needed only when tested app is a Chromium embedding browser. The socket is open by the browser and Chromedriver connects to it as a devtools client.	e.g., chrome_devtools_remote
avd	Name of avd to launch	e.g., api19
avdLaunchTimeout	How long to wait in milliseconds for an avd to launch and connect to ADB (default 120000)	300000
avdReadyTimeout	How long to wait in milliseconds for an avd to finish its boot animations (default 120000)	300000
avdArgs	Additional emulator arguments used when launching an avd	e.g., -netfast
useKeystore	Use a custom keystore to sign apks, default false	true or false
keystorePath	Path to custom keystore, default ~/.android/debug.keystore	e.g., /path/to.keystore
keystorePassword	Password for custom keystore	e.g., foo
keyAlias	Alias for key	e.g., androiddebugkey
keyPassword	Password for key	e.g., foo
chromedriverExecutable	The absolute local path to webdriver executable (if Chromium embedder provides its own webdriver, it should be used instead of original chromedriver bundled with Appium)	/abs/path/to/webdriver
chromedriverExecutableDir	The absolute path to a directory to look for Chromedriver executables in, for automatic discovery of compatible Chromedrivers. Ignored if chromedriverUseSystemExecutableis true	/abs/path/to/chromedriver /directory
chromedriver ChromeMappingFile	The absolute path to a file which maps Chromedriver versions to the minimum Chrome that it supports. Ignored if chromedriverUseSystemExecutableis true	/abs/path/to/mapping.json
chromedriverUse SystemExecutable	If true, bypasses automatic Chromedriver configuration and uses the version that comes downloaded with Appium. Ignored if chromedriverExecutable is set. Defaults to false	e.g., true
autoWebviewTimeout	Amount of time to wait for Webview context to become active, in ms. Defaults to 2000	e.g. 4
intentAction	Intent action which will be used to start activity (default android.intent.action.MAIN)	e.g.android.intent.action.MAIN, android.intent.action.VIEW
intentCategory	Intent category which will be used to start activity (default android.intent.category.LAUNCHER)	e.g. android.intent.category. LAUNCHER, android .intent.category. APP_CONTACTS
intentFlags	Flags that will be used to start activity (default 0x10200000)	e.g. 0x10200000
optionalIntentArguments	Additional intent arguments that will be used to start activity. See Intent arguments	e.g. –esn <EXTRA_KEY>, –ez <EXTRA_KEY> <EXTRA_BOOLEAN_VALUE>, etc.
dontStopAppOnReset	Doesn’t stop the process of the app under test, before starting the app using adb. If the app under test is created by another anchor app, setting this false, allows the process of the anchor app to be still alive, during the start of the test app using adb. In other words, with dontStopAppOnReset set to true, we will not include the -Sflag in the adb shell am start call. With this capability omitted or set to false, we include the -S flag. Default false	true or false
unicodeKeyboard	Enable Unicode input, default false	true or false
resetKeyboard	Reset keyboard to its original state, after running Unicode tests with unicodeKeyboard capability. Ignored if used alone. Default false	true or false
noSign	Skip checking and signing of app with debug keys, will work only with UiAutomator and not with selendroid, default false	true or false
ignoreUnimportantViews	Calls the setCompressedLayoutHierarchy()uiautomator function. This capability can speed up test execution, since Accessibility commands will run faster ignoring some elements. The ignored elements will not be findable, which is why this capability has also been implemented as a toggle-able setting as well as a capability. Defaults to false	true or false
disableAndroidWatchers	Disables android watchers that watch for application not responding and application crash, this will reduce cpu usage on android device/emulator. This capability will work only with UiAutomator and not with selendroid, default false	true or false
chromeOptions	Allows passing chromeOptions capability for ChromeDriver. For more information see chromeOptions	chromeOptions: {args: [‘–disable-popup-blocking’]}
recreateChromeDriverSessions	Kill ChromeDriver session when moving to a non-ChromeDriver webview. Defaults to false	true or false
nativeWebScreenshot	In a web context, use native (adb) method for taking a screenshot, rather than proxying to ChromeDriver. Defaults to false	true or false
androidScreenshotPath	The name of the directory on the device in which the screenshot will be put. Defaults to /data/local/tmp	e.g. /sdcard/screenshots/
autoGrantPermissions	Have Appium automatically determine which permissions your app requires and grant them to the app on install. Defaults to false. If noReset is true, this capability doesn’t work.	true or false
networkSpeed	Set the network speed emulation. Specify the maximum network upload and download speeds. Defaults to full	[‘full’,’gsm’, ‘edge’, ‘hscsd’, ‘gprs’, ‘umts’, ‘hsdpa’, ‘lte’, ‘evdo’]Check -netspeed option more info about speed emulation for avds
gpsEnabled	Toggle gps location provider for emulators before starting the session. By default the emulator will have this option enabled or not according to how it has been provisioned.	true or false
isHeadless	Set this capability to true to run the Emulator headless when device display is not needed to be visible. false is the default value. isHeadless is also support for iOS, check XCUITest-specific capabilities.	e.g., true
uiautomator2Server LaunchTimeout	Timeout in milliseconds used to wait for an uiAutomator2 server to launch. Defaults to 20000	e.g., 20000
uiautomator2Server InstallTimeout	Timeout in milliseconds used to wait for an uiAutomator2 server to be installed. Defaults to 20000	e.g., 20000
otherApps	App or list of apps (as a JSON array) to install prior to running tests	e.g., “/path/to/app.apk”, https://www.example.com/url/to/app.apk, [“/path/to/app-a.apk”, “/path/to/app-b.apk”]

iOS Capabilities

These capabilities are available only on the XCUITest Driver and the deprecated UIAutomation Driver.

Capability	Description	Values
calendarFormat	(Sim-only) Calendar format to set for the iOS Simulator	e.g. gregorian
bundleId	Bundle ID of the app under test. Useful for starting an app on a real device or for using other caps which require the bundle ID during test startup. To run a test on a real device using the bundle ID, you may omit the ‘app’ capability, but you must provide ‘udid’.	e.g. io.appium.TestApp
udid	Unique device identifier of the connected physical device	e.g. 1ae203187fc012g
launchTimeout	Amount of time in ms to wait for instruments before assuming it hung and failing the session	e.g. 20000
locationServicesEnabled	(Sim-only) Force location services to be either on or off. Default is to keep current sim setting.	true or false
locationServicesAuthorized	(Sim-only) Set location services to be authorized or not authorized for app via plist, so that location services alert doesn’t pop up. Default is to keep current sim setting. Note that if you use this setting you MUST also use the bundleId capability to send in your app’s bundle ID.	true or false
autoAcceptAlerts	Accept all iOS alerts automatically if they pop up. This includes privacy access permission alerts (e.g., location, contacts, photos). Default is false. Does not work on XCUITest-based tests.	true or false
autoDismissAlerts	Dismiss all iOS alerts automatically if they pop up. This includes privacy access permission alerts (e.g., location, contacts, photos). Default is false. Does not work on XCUITest-based tests.	true or false
nativeInstrumentsLib	Use native intruments lib (ie disable instruments-without-delay).	true or false
nativeWebTap	(Sim-only) Enable “real”, non-javascript-based web taps in Safari. Default: false. Warning: depending on viewport size/ratio this might not accurately tap an element	true or false
safariInitialUrl	(Sim-only) (>= 8.1) Initial safari url, default is a local welcome page	e.g. https://www.github.com
safariAllowPopups	(Sim-only) Allow javascript to open new windows in Safari. Default keeps current sim setting	true or false
safariIgnoreFraudWarning	(Sim-only) Prevent Safari from showing a fraudulent website warning. Default keeps current sim setting.	true or false
safariOpenLinksInBackground	(Sim-only) Whether Safari should allow links to open in new windows. Default keeps current sim setting.	true or false
keepKeyChains	(Sim-only) Whether to keep keychains (Library/Keychains) when appium session is started/finished	true or false
localizableStringsDir	Where to look for localizable strings. Default en.lproj	en.lproj
processArguments	Arguments to pass to the AUT using instruments	e.g., -myflag
interKeyDelay	The delay, in ms, between keystrokes sent to an element when typing.	e.g., 100
showIOSLog	Whether to show any logs captured from a device in the appium logs. Default false	true or false
sendKeyStrategy	strategy to use to type test into a test field. Simulator default: oneByOne. Real device default: grouped	oneByOne, grouped or setValue
screenshotWaitTimeout	Max timeout in sec to wait for a screenshot to be generated. default: 10	e.g., 5
waitForAppScript	The ios automation script used to determined if the app has been launched, by default the system wait for the page source not to be empty. The result must be a boolean	e.g. true;, target.elements().length > 0;, $.delay(5000); true;
webviewConnectRetries	Number of times to send connection message to remote debugger, to get webview. Default: 8	e.g., 12
appName	The display name of the application under test. Used to automate backgrounding the app in iOS 9+.	e.g., UICatalog
customSSLCert	(Sim only) Add an SSL certificate to IOS Simulator.	e.g.—–BEGIN CERTIFICATE—–MIIFWjCCBEKg…—–END CERTIFICATE—–
webkitResponseTimeout	(Real device only) Set the time, in ms, to wait for a response from WebKit in a Safari session. Defaults to 5000	e.g., 10000
remoteDebugProxy	(Sim only, <= 11.2) If set, Appium sends and receives remote debugging messages through a proxy on either the local port (Sim only, <= 11.2) or a proxy on this unix socket (Sim only >= 11.3) instead of communicating with the iOS remote debugger directly.	e.g. 12000 or “/tmp/my.proxy.socket”

Important Capabilities

Reset strategies

In Mobile Application Automation, most of the execution time is spent on Application installation. Sometimes, you do not want to reinstall the application (like between tests). In this case, Appium has provided 2 capabilities named noReset and fullReset, which provides control over application installation where you can leverage the right combination of the two flags.

noReset	fullReset	Result on iOS	Result on Android
true	true	Error: The ‘noReset’ and ‘fullReset’ capabilities are mutually exclusive and should not both be set to true
true	false	Do not destroy or shut down simulator after test. Start tests running on whichever simulator is running, or device is plugged in.	Do not stop app, do not clear app data, and do not uninstall apk.
false	true	Uninstall app after real device test, destroy Simulator after sim test.	Stop app, clear app data and uninstall apk after test.
false	false	Shut down simulator after test. Do not destroy simulator. Do not uninstall app from real device.	Stop and clear app data after test. Do not uninstall apk

NOTE: You can know more about Appium Capabilities on Official Appium Docs periodically: appium.

The following additional capabilities are reprinted with permission from Jonathan Lipps, Founding Principal of Cloud Grey, a mobile testing services company. Refer to footnote for the source link.

Android-specific Capabilities

disableAndroidWatchers: The only way to check for toast messages on Android is for the Appium UiAutomator2 driver to run a loop, constantly checking the state of the device. Running a loop like this takes up valuable CPU cycles and has been observed to make scrolling less consistent, for example. If you don’t need the features that require the watcher loop (like toast verification), then set this cap to true to turn it off entirely and save your device some cycles.

autoGrantPermission: Set to true to have Appium attempt to automatically determine your app permissions and grant them. For example, to avoid system pop ups asking for permission later on in the test.

skipUnlock: Appium doesn’t assume that your device is unlocked, and it should be to successfully run tests. So, it installs and runs a little helper app that tries to unlock the screen before a test. Sometimes this works, and sometimes this doesn’t. But that’s beside the point: either way, it takes time! If you know your screen is unlocked, because you’re managing screen state with something other than Appium, tell Appium not to bother with this little startup routine and save yourself a second or three, by setting this cap to true.

appWaitPackage and appWaitActivity: Android activities can be kind of funny. In many apps, the activity used to launch the app is not the same as the activity, which is active when the user initially interacts with the application. Typically, it’s this latter activity you care about when you run an Appium test. You want to make sure that Appium doesn’t consider the session started until this activity is active, regardless of what happened to the launch activity.

In this scenario, you need to tell Appium to wait for the correct activity, since the one it automatically retrieves from your app manifest will be the launch activity. You can use the appWaitPackage and appWaitActivity to tell Appium to consider a session started (and hence return control to your test code) only when the package and activity specified have become active. This can greatly help the stability of session start, because your test code can assume your app is on the activity expects when the session starts.

ignoreUnimportantViews: Android has two modes for expressing its layout hierarchy: normal and “compressed”. The compressed layout hierarchy is a subset of the hierarchy that the OS itself sees, restricted to elements which the OS thinks are more relevant for users. For example, elements with accessibility information set on them. Because compressed mode generates a smaller XML file, and perhaps for other Android-internal reasons, it’s often faster to get the hierarchy in compressed mode. If you’re running into page source queries taking a very long time, you might try setting this cap to true.

Note that the XML returned in the different modes is … different. This means that XPath queries that worked in one mode will likely not work in the other. Make sure you don’t change this back and forth if you rely on XPath!

iOS-specific Capabilities

usePrebuiltWDA and derivedDataPath: Typically, Appium uses xcodebuild under the hood to both build WebDriverAgent and kick off the XCUITest process that powers the test session. If you have a prebuilt WebDriverAgent binary and would like to save some time on startup, set the usePrebuiltWDA cap to true. This cap could be used in conjunction with derivedDataPath, which is the path to the derived data folder where your WebDriverAgent binary is dumped by Xcode.

useJSONSource: For large applications, it can be faster for Appium to deal with the app hierarchy internally as JSON, rather than XML, and convert it to XML at the “edge”, so to speak—in the Appium driver itself, rather than lower in the stack. Basically, give this a try if getting the iOS app source is taking forever.

iosInstallPause: Sometimes, large iOS applications can take a while to launch, but there’s no way for Appium to automatically detect when an app is ready for use or not. If you have such an app, set this cap to the number of milliseconds you’d like Appium to wait after WebDriverAgent thinks the app is online, before Appium hands back control to your test script. It might help make session startup a bit more stable.

maxTypingFrequency: If you notice errors during typing, for example the wrong keys being pressed or visual oddities you notice while watching a test, try slowing the typing down. Set this cap to an integer and play around with the value until things work. Lower is slower, higher is faster! The default is 60.

realDeviceScreenshotter: Appium has its own methods for capturing screenshots from simulators and devices, but especially on real devices this can be slow and/or flaky. If you’re a fan of the libimobiledevice suite and happen to have idevicescreenshot on your system, you can use this cap to let Appium know you’d prefer to retrieve the screenshot via a call to that binary instead of using its own internal methods. To make it happen, simply set this cap to the string “idevicescreenshot”!

simpleIsVisibleCheck: Element visibility checks in XCUITest are fraught with flakiness and complexity. By default, the visibility checks available don’t always do a great job. Appium implemented another type of visibility check inside of WebDriverAgent that might be more reliable for your app, though, it comes with the downside that the checks could take longer for some apps. As with many things in life, we sometimes have to make trade-offs between speed and reliability.

We suggest reviewing these capabilities and familiarizing yourself with them. It isn’t necessary to memorize them, but as you get more sophisticated testing needs, it will be good to keep coming back here to see which one will do the trick. We’ll be using various forms of these capabilities throughout these Appium articles, so you will start getting more familiar with them as we work through more examples.

Appium Desired Capabilities help us to configure the Appium server and provide the criteria which we wish to use for running our automation script. 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.

In this article, we will take a deep dive into this feature. Previously, we introduced you to Appium Desired Capabilities. This is a core capability of Appium, and if you missed it, you should also go back and review.

Figure-1:Appium Architecture.

DesiredCapabilities is a predefined library and in order to use it you need to import:

Org.openqa.selenium.remote.DesiredCapabilities

As Appium supports both Android and iOS, There are separate capabilities for both. However most of the capabilities remain common to both platforms.

Android:

{
 "platformName": "Android",
 "platformVersion": "8.0",
 "app": "/Users/username/Downloads/sample.apk",
 "deviceName": "c4e3f3cda"
 "automationName": "UiAutomator2"
}

iOS:

{
 "platformName": "iOS",
 "platformVersion": "11.4.1",
 "app": "/path/to/.ipa/file",
 "deviceName": "John’s iPhone",
 "udid": "bea36e2b0262ae4b77bd3463bd462922ee935d24"
 "automationName": "XCUITest"
}

The above is the JSON representation. To use this in code you can define the Desired Capabilities (for Android) as below:

DesiredCapabilities dc = new DesiredCapabilities();
dc.setCapability("platformName", "Android");
dc.setCapability("platformVersion", "8.0");
dc.setCapability("app", "/Users/test/Downloads/FirstAutomationTest/src/test/resources/DemoApp.apk");
dc.setCapability("deviceName", "c4e3f3cd");
dc.setCapability("automationName", "UiAutomator2");

In the above code snippet instead of defining Capability Name in a String you can use the Appium predefined interfaces such as MobileCapabilityType, IOSMobileCapabilityType and AndroidMobileCapabilityType to get Capability Names, so the above code snippet can be written in a better way:

DesiredCapabilities dc = new DesiredCapabilities();
dc.setCapability(MobileCapabilityType.PLATFORM_NAME, "Android");
dc.setCapability(MobileCapabilityType.PLATFORM_VERSION, "8.0");
dc.setCapability(MobileCapabilityType.APP, "/Users/test/Downloads/FirstAutomationTest/src/test/resources/DemoApp.apk");
dc.setCapability(MobileCapabilityType.DEVICE_NAME, "c4e3f3cd");
dc.setCapability(MobileCapabilityType.AUTOMATION_NAME, "UiAutomator2");

 

Desired capabilities for iOS and Android

We have many desired capabilities at our disposal depending on what we are trying to accomplish. However, there are specific capabilities we need to set based on what we are trying to test:

• Mobile Web Android.
• Mobile Web iOS.
• Mobile Native Android.
• Mobile Native iOS.

 

Mobile web – Android

If you want to automate the Chrome browser on Android device then you need to use these Desired Capabilities.

DesiredCapabilities dc = new DesiredCapabilities();
dc.setCapability(MobileCapabilityType.PLATFORM_NAME, "Android");
dc.setCapability(MobileCapabilityType.PLATFORM_VERSION, "OS version of your test device/simulator");
dc.setCapability(MobileCapabilityType.DEVICE_NAME, "Name of your test device");
// This capability will open the Chrome browser instead of Native app.
dc.setCapability(MobileCapabilityType.BROWSER_NAME, MobileBrowserType.CHROME);
dc.setCapability(MobileCapabilityType.AUTOMATION_NAME, "UiAutomator2");

 

Mobile web – iOS

DesiredCapabilities dc = new DesiredCapabilities();
dc.setCapability(MobileCapabilityType.PLATFORM_NAME, "iOS");
dc.setCapability(MobileCapabilityType.PLATFORM_VERSION, "OS version of your test device/simulator");
dc.setCapability(MobileCapabilityType.DEVICE_NAME, "Name of your test device");
// This capability will open the Safari browser instead of Native app.
dc.setCapability(MobileCapabilityType.BROWSER_NAME, MobileBrowserType.SAFARI);
dc.setCapability(MobileCapabilityType.AUTOMATION_NAME, "XCUITest");
// If you are using Real iPhone device then you need to specify "udid" of device.
dc.setCapability("udid", "UDID of your test device");

 

Mobile native – Android

DesiredCapabilities dc = new DesiredCapabilities();
dc.setCapability(MobileCapabilityType.PLATFORM_NAME, "Android");
dc.setCapability(MobileCapabilityType.PLATFORM_VERSION, "OS version of your test device/simulator");
dc.setCapability(MobileCapabilityType.APP, "/path/to/.apk/file");
dc.setCapability(MobileCapabilityType.DEVICE_NAME, "Name of your test device");
dc.setCapability(MobileCapabilityType.AUTOMATION_NAME, "UiAutomator2");

 

Mobile native – iOS

DesiredCapabilities dc = new DesiredCapabilities();
dc.setCapability(MobileCapabilityType.PLATFORM_NAME, "iOS");
dc.setCapability(MobileCapabilityType.PLATFORM_VERSION, "OS version of your test device/simulator");
dc.setCapability(MobileCapabilityType.APP, "/path/to/.app or .ipa/file");
dc.setCapability(MobileCapabilityType.DEVICE_NAME, "Name of your test device");
dc.setCapability(MobileCapabilityType.AUTOMATION_NAME, "XCUITest");

List of all capabilities

There are many, many capabilities that Appium supports. We can categorize the Capabilities into 3 parts:

• General Capabilities.
• iOS Capabilities.
• Android Capabilities.

While you clearly don’t need to memorize all of these, we do suggest you spend the time to familiarize yourself with these capabilities. As you use Appium more and more and continue to consult this list, you will eventually have a good sense of what capabilities are available to you.

General capabilities

 

Capability	Description	Values
automationName	Which automation engine to use	Appium (default) or Selendroid or UiAutomator2 or Espresso for Android or XCUITest for iOS
platformName	Which mobile OS platform to use	iOS, Android, or Firefox OS
platformVersion	Mobile OS version	e.g., 7.1, 4.4
deviceName	The kind of mobile device or emulator to use	iPhone Simulator, iPad Simulator, iPhone Retina 4-inch, Android Emulator, Galaxy S4, etc…. On iOS, this should be one of the valid devices returned by instruments with instruments -s devices. On Android this capability is currently ignored, though it remains required.
app	The absolute local path or remote http URL to a .ipa file (IOS), .app folder (IOS Simulator) or .apk file (Android), or a .zip file containing one of these (for .app, the .app folder must be the root of the zip file). Appium will attempt to install this app binary on the appropriate device first. Note that this capability is not required for Android if you specify appPackage and appActivity capabilities (see below). Incompatible with browserName.	/abs/path/to/my.apk or https://myapp.com/app.ipa
browserName	Name of mobile web browser to automate. Should be an empty string if automating an app instead.	‘Safari’ for iOS and ‘Chrome’, ‘Chromium’, or ‘Browser’ for Android
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
language	(Sim/Emu-only) Language to set for the simulator / emulator. On Android, available only on API levels 22 and below	e.g. fr
locale	(Sim/Emu-only) Locale to set for the simulator / emulator.	e.g. fr_CA
udid	Unique device identifier of the connected physical device	e.g. 1ae203187fc012g
orientation	(Sim/Emu-only) start in a certain orientation	LANDSCAPE or PORTRAIT
autoWebview	Move directly into Webview context. Default false	true, false
noReset	Don’t reset app state before this session.	true, false
fullReset	Perform a complete reset.	true, false
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 reported as events property on response to querying the current session.	e.g., true
enablePerformanceLogging	(Web and webview only) Enable Chromedriver’s (on Android) or Safari’s (on iOS) performance logging (default false)	true, false
printPageSourceOnFindFailure	When a find operation fails, print the current page source. Defaults to false.	e.g., true

 

Android capabilities

These Capabilities are available only on Android-based drivers (like UiAutomator2 for example).

Capability	Description	Values
appActivity	Activity name for the Android activity you want to launch from your package. This often needs to be preceded by a . (e.g., .MainActivity instead of MainActivity). By default this capability is received from the package manifest (action: android.intent.action.MAIN , category: android.intent.category.LAUNCHER)	MainActivity, .Settings
appPackage	Java package of the Android app you want to run. By default this capability is received from the package manifest (@package attribute value)	com.example.android.myApp, com.android.settings
appWaitActivity	Activity name/names, comma separated, for the Android activity you want to wait for. By default the value of this capability is the same as for appActivity. You must set it to the very first focused application activity name in case it is different from the one which is set as appActivity if your capability has appActivity and appPackage.	SplashActivity, SplashActivity,OtherActivity, *, *.SplashActivity
appWaitPackage	Java package of the Android app you want to wait for. By default the value of this capability is the same as for appActivity	com.example.android.myApp, com.android.settings
appWaitDuration	Timeout in milliseconds used to wait for the appWaitActivity to launch (default 20000)	30000
deviceReadyTimeout	Timeout in seconds while waiting for device to become ready	5
androidCoverage	Fully qualified instrumentation class. Passed to -w in adb shell am instrument -e coverage true -w	com.my.Pkg/com.my.Pkg .instrumentation.MyInstrumentation
androidCoverageEndIntent	A broadcast action implemented by yourself which is used to dump coverage into file system. Passed to -a in adb shell am broadcast -a	com.example.pkg.END_EMMA
androidDeviceReadyTimeout	Timeout in seconds used to wait for a device to become ready after booting	e.g., 30
androidInstallTimeout	Timeout in milliseconds used to wait for an apk to install to the device. Defaults to 90000	e.g., 90000
androidInstallPath	The name of the directory on the device in which the apk will be push before install. Defaults to /data/local/tmp	e.g. /sdcard/Downloads/
adbPort	Port used to connect to the ADB server (default 5037)	5037
systemPort	systemPort used to connect to appium-uiautomator2-server, default is 8200 in general and selects one port from 8200 to 8299. When you run tests in parallel, you must adjust the port to avoid conflicts.	e.g., 8201
remoteAdbHost	Optional remote ADB server host	e.g.: 192.168.0.101
androidDeviceSocket	Devtools socket name. Needed only when tested app is a Chromium embedding browser. The socket is open by the browser and Chromedriver connects to it as a devtools client.	e.g., chrome_devtools_remote
avd	Name of avd to launch	e.g., api19
avdLaunchTimeout	How long to wait in milliseconds for an avd to launch and connect to ADB (default 120000)	300000
avdReadyTimeout	How long to wait in milliseconds for an avd to finish its boot animations (default 120000)	300000
avdArgs	Additional emulator arguments used when launching an avd	e.g., -netfast
useKeystore	Use a custom keystore to sign apks, default false	true or false
keystorePath	Path to custom keystore, default ~/.android/debug.keystore	e.g., /path/to.keystore
keystorePassword	Password for custom keystore	e.g., foo
keyAlias	Alias for key	e.g., androiddebugkey
keyPassword	Password for key	e.g., foo
chromedriverExecutable	The absolute local path to webdriver executable (if Chromium embedder provides its own webdriver, it should be used instead of original chromedriver bundled with Appium)	/abs/path/to/webdriver
chromedriverExecutableDir	The absolute path to a directory to look for Chromedriver executables in, for automatic discovery of compatible Chromedrivers. Ignored if chromedriverUseSystemExecutableis true	/abs/path/to/chromedriver /directory
chromedriver ChromeMappingFile	The absolute path to a file which maps Chromedriver versions to the minimum Chrome that it supports. Ignored if chromedriverUseSystemExecutableis true	/abs/path/to/mapping.json
chromedriverUse SystemExecutable	If true, bypasses automatic Chromedriver configuration and uses the version that comes downloaded with Appium. Ignored if chromedriverExecutable is set. Defaults to false	e.g., true
autoWebviewTimeout	Amount of time to wait for Webview context to become active, in ms. Defaults to 2000	e.g. 4
intentAction	Intent action which will be used to start activity (default android.intent.action.MAIN)	e.g.android.intent.action.MAIN, android.intent.action.VIEW
intentCategory	Intent category which will be used to start activity (default android.intent.category.LAUNCHER)	e.g. android.intent.category. LAUNCHER, android .intent.category. APP_CONTACTS
intentFlags	Flags that will be used to start activity (default 0x10200000)	e.g. 0x10200000
optionalIntentArguments	Additional intent arguments that will be used to start activity. See Intent arguments	e.g. –esn <EXTRA_KEY>, –ez <EXTRA_KEY> <EXTRA_BOOLEAN_VALUE>, etc.
dontStopAppOnReset	Doesn’t stop the process of the app under test, before starting the app using adb. If the app under test is created by another anchor app, setting this false, allows the process of the anchor app to be still alive, during the start of the test app using adb. In other words, with dontStopAppOnReset set to true, we will not include the -Sflag in the adb shell am start call. With this capability omitted or set to false, we include the -S flag. Default false	true or false
unicodeKeyboard	Enable Unicode input, default false	true or false
resetKeyboard	Reset keyboard to its original state, after running Unicode tests with unicodeKeyboard capability. Ignored if used alone. Default false	true or false
noSign	Skip checking and signing of app with debug keys, will work only with UiAutomator and not with selendroid, default false	true or false
ignoreUnimportantViews	Calls the setCompressedLayoutHierarchy()uiautomator function. This capability can speed up test execution, since Accessibility commands will run faster ignoring some elements. The ignored elements will not be findable, which is why this capability has also been implemented as a toggle-able setting as well as a capability. Defaults to false	true or false
disableAndroidWatchers	Disables android watchers that watch for application not responding and application crash, this will reduce cpu usage on android device/emulator. This capability will work only with UiAutomator and not with selendroid, default false	true or false
chromeOptions	Allows passing chromeOptions capability for ChromeDriver. For more information see chromeOptions	chromeOptions: {args: [‘–disable-popup-blocking’]}
recreateChromeDriverSessions	Kill ChromeDriver session when moving to a non-ChromeDriver webview. Defaults to false	true or false
nativeWebScreenshot	In a web context, use native (adb) method for taking a screenshot, rather than proxying to ChromeDriver. Defaults to false	true or false
androidScreenshotPath	The name of the directory on the device in which the screenshot will be put. Defaults to /data/local/tmp	e.g. /sdcard/screenshots/
autoGrantPermissions	Have Appium automatically determine which permissions your app requires and grant them to the app on install. Defaults to false. If noReset is true, this capability doesn’t work.	true or false
networkSpeed	Set the network speed emulation. Specify the maximum network upload and download speeds. Defaults to full	[‘full’,’gsm’, ‘edge’, ‘hscsd’, ‘gprs’, ‘umts’, ‘hsdpa’, ‘lte’, ‘evdo’]Check -netspeed option more info about speed emulation for avds
gpsEnabled	Toggle gps location provider for emulators before starting the session. By default the emulator will have this option enabled or not according to how it has been provisioned.	true or false
isHeadless	Set this capability to true to run the Emulator headless when device display is not needed to be visible. false is the default value. isHeadless is also support for iOS, check XCUITest-specific capabilities.	e.g., true
uiautomator2Server LaunchTimeout	Timeout in milliseconds used to wait for an uiAutomator2 server to launch. Defaults to 20000	e.g., 20000
uiautomator2Server InstallTimeout	Timeout in milliseconds used to wait for an uiAutomator2 server to be installed. Defaults to 20000	e.g., 20000
otherApps	App or list of apps (as a JSON array) to install prior to running tests	e.g., “/path/to/app.apk”, https://www.example.com/url/to/app.apk, [“/path/to/app-a.apk”, “/path/to/app-b.apk”]

 

iOS capabilities

These Capabilities are available only on the XCUITest Driver and the deprecated UIAutomation Driver.

Capability	Description	Values
calendarFormat	(Sim-only) Calendar format to set for the iOS Simulator	e.g. gregorian
bundleId	Bundle ID of the app under test. Useful for starting an app on a real device or for using other caps which require the bundle ID during test startup. To run a test on a real device using the bundle ID, you may omit the ‘app’ capability, but you must provide ‘udid’.	e.g. io.appium.TestApp
udid	Unique device identifier of the connected physical device	e.g. 1ae203187fc012g
launchTimeout	Amount of time in ms to wait for instruments before assuming it hung and failing the session	e.g. 20000
locationServicesEnabled	(Sim-only) Force location services to be either on or off. Default is to keep current sim setting.	true or false
locationServicesAuthorized	(Sim-only) Set location services to be authorized or not authorized for app via plist, so that location services alert doesn’t pop up. Default is to keep current sim setting. Note that if you use this setting you MUST also use the bundleId capability to send in your app’s bundle ID.	true or false
autoAcceptAlerts	Accept all iOS alerts automatically if they pop up. This includes privacy access permission alerts (e.g., location, contacts, photos). Default is false. Does not work on XCUITest-based tests.	true or false
autoDismissAlerts	Dismiss all iOS alerts automatically if they pop up. This includes privacy access permission alerts (e.g., location, contacts, photos). Default is false. Does not work on XCUITest-based tests.	true or false
nativeInstrumentsLib	Use native intruments lib (ie disable instruments-without-delay).	true or false
nativeWebTap	(Sim-only) Enable “real”, non-javascript-based web taps in Safari. Default: false. Warning: depending on viewport size/ratio this might not accurately tap an element	true or false
safariInitialUrl	(Sim-only) (>= 8.1) Initial safari url, default is a local welcome page	e.g. https://www.github.com
safariAllowPopups	(Sim-only) Allow javascript to open new windows in Safari. Default keeps current sim setting	true or false
safariIgnoreFraudWarning	(Sim-only) Prevent Safari from showing a fraudulent website warning. Default keeps current sim setting.	true or false
safariOpenLinksInBackground	(Sim-only) Whether Safari should allow links to open in new windows. Default keeps current sim setting.	true or false
keepKeyChains	(Sim-only) Whether to keep keychains (Library/Keychains) when appium session is started/finished	true or false
localizableStringsDir	Where to look for localizable strings. Default en.lproj	en.lproj
processArguments	Arguments to pass to the AUT using instruments	e.g., -myflag
interKeyDelay	The delay, in ms, between keystrokes sent to an element when typing.	e.g., 100
showIOSLog	Whether to show any logs captured from a device in the appium logs. Default false	true or false
sendKeyStrategy	strategy to use to type test into a test field. Simulator default: oneByOne. Real device default: grouped	oneByOne, grouped or setValue
screenshotWaitTimeout	Max timeout in sec to wait for a screenshot to be generated. default: 10	e.g., 5
waitForAppScript	The ios automation script used to determined if the app has been launched, by default the system wait for the page source not to be empty. The result must be a boolean	e.g. true;, target.elements().length > 0;, $.delay(5000); true;
webviewConnectRetries	Number of times to send connection message to remote debugger, to get webview. Default: 8	e.g., 12
appName	The display name of the application under test. Used to automate backgrounding the app in iOS 9+.	e.g., UICatalog
customSSLCert	(Sim only) Add an SSL certificate to IOS Simulator.	e.g. —–BEGIN CERTIFICATE—–MIIFWjCCBEKg… —–END CERTIFICATE—–
webkitResponseTimeout	(Real device only) Set the time, in ms, to wait for a response from WebKit in a Safari session. Defaults to 5000	e.g., 10000
remoteDebugProxy	(Sim only, <= 11.2) If set, Appium sends and receives remote debugging messages through a proxy on either the local port (Sim only, <= 11.2) or a proxy on this unix socket (Sim only >= 11.3) instead of communicating with the iOS remote debugger directly.	e.g. 12000 or “/tmp/my.proxy.socket”

 

Important capabilities

Reset strategies

In Mobile Application Automation, most of the execution time is spent on Application installation. Sometimes you do not want to reinstall the application (like between tests) so Appium has provided 2 capabilities named noReset and fullReset which provides control over application installation and you can leverage the right combination of the two flags.

noReset	fullReset	Result on iOS	Result on Android
true	true	Error: The ‘noReset’ and ‘fullReset’ capabilities are mutually exclusive and should not both be set to true
true	false	Do not destroy or shut down simulator after test. Start tests running on whichever simulator is running, or device is plugged in.	Do not stop app, do not clear app data, and do not uninstall apk.
false	true	Uninstall app after real device test, destroy Simulator after sim test.	Stop app, clear app data and uninstall apk after test.
false	false	Shut down simulator after test. Do not destroy simulator. Do not uninstall app from real device.	Stop and clear app data after test. Do not uninstall apk

NOTE: You can know more about Appium Capabilities on Official Appium Docs periodically: https://appium.io/docs/

The following additional capabilities are reprinted with permission from Jonathan Lipps, Founding Principal of Cloud Grey, a mobile testing services company. Refer to footnote for the source link.

Android-specific capabilities

disableAndroidWatchers:
The only way to check for toast messages on Android is for the Appium UiAutomator2 driver to run a loop constantly checking the state of the device. Running a loop like this takes up valuable CPU cycles and has been observed to make scrolling less consistent, for example. If you don’t need the features that require the watcher loop (like toast verification), then set this cap to true to turn it off entirely and save your device some cycles.

autoGrantPermission:
Set to true to have Appium attempt to automatically determine your app permissions and grant them, for example to avoid system pop ups asking for permission later on in the test.

skipUnlock:
Appium doesn’t assume that your device is unlocked, and it should be to successfully run tests. So it installs and runs a little helper app that tries to unlock the screen before a test. Sometimes this works, and sometimes this doesn’t. But that’s beside the point: either way, it takes time! If you know your screen is unlocked, because you’re managing screen state with something other than Appium, tell Appium not to bother with this little startup routine and save yourself a second or three, by setting this cap to true.

appWaitPackage and appWaitActivity:
Android activities can be kind of funny. In many apps, the activity used to launch the app is not the same as the activity which is active when the user initially interacts with the application. Typically it’s this latter activity you care about when you run an Appium test. You want to make sure that Appium doesn’t consider the session started until this activity is active, regardless of what happened to the launch activity.

In this scenario, you need to tell Appium to wait for the correct activity, since the one it automatically retrieves from your app manifest will be the launch activity. You can use the appWaitPackage and appWaitActivity to tell Appium to consider a session started (and hence return control to your test code) only when the package and activity specified have become active. This can greatly help the stability of session start, because your test code can assume your app is on the activity expects when the session starts.

ignoreUnimportantViews:
Android has two modes for expressing its layout hierarchy: normal and “compressed”. The compressed layout hierarchy is a subset of the hierarchy that the OS itself sees, restricted to elements which the OS thinks are more relevant for users, for example elements with accessibility information set on them. Because compressed mode generates a smaller XML file, and perhaps for other Android-internal reasons, it’s often faster to get the hierarchy in compressed mode. If you’re running into page source queries taking a very long time, you might try setting this cap to true.

Note that the XML returned in the different modes is … different. Which means that XPath queries that worked in one mode will likely not work in the other. Make sure you don’t change this back and forth if you rely on XPath!

iOS-specific capabilities

usePrebuiltWDA and derivedDataPath:
Typically, Appium uses xcodebuild under the hood to both build WebDriverAgent and kick off the XCUITest process that powers the test session. If you have a prebuilt WebDriverAgent binary and would like to save some time on startup, set the usePrebuiltWDA cap to true. This cap could be used in conjunction with derivedDataPath, which is the path to the derived data folder where your WebDriverAgent binary is dumped by Xcode.

useJSONSource:
For large applications, it can be faster for Appium to deal with the app hierarchy internally as JSON, rather than XML, and convert it to XML at the “edge”, so to speak—in the Appium driver itself, rather than lower in the stack. Basically, give this a try if getting the iOS app source is taking forever.

iosInstallPause:
Sometimes, large iOS applications can take a while to launch, but there’s no way for Appium to automatically detect when an app is ready for use or not. If you have such an app, set this cap to the number of milliseconds you’d like Appium to wait after WebDriverAgent thinks the app is online, before Appium hands back control to your test script. It might help make session startup a bit more stable.

maxTypingFrequency:
If you notice errors during typing, for example the wrong keys being pressed or visual oddities you notice while watching a test, try slowing the typing down. Set this cap to an integer and play around with the value until things work. Lower is slower, higher is faster! The default is 60.

realDeviceScreenshotter:
Appium has its own methods for capturing screenshots from simulators and devices, but especially on real devices this can be slow and/or flaky. If you’re a fan of the libimobiledevice suite and happen to have idevicescreenshot on your system, you can use this cap to let Appium know you’d prefer to retrieve the screenshot via a call to that binary instead of using its own internal methods. To make it happen, simply set this cap to the string “idevicescreenshot”!

simpleIsVisibleCheck:
Element visibility checks in XCUITest are fraught with flakiness and complexity. By default, the visibility checks available don’t always do a great job. Appium implemented another type of visibility check inside of WebDriverAgent that might be more reliable for your app, though it comes with the downside that the checks could take longer for some apps. As with many things in life, we sometimes have to make trade-offs between speed and reliability.