In this article, I would like to share different Appium drivers and how to choose which one to use in the automation situation. Appium is not just one “thing”. It can automate multiple platforms, from iOS to Android and beyond. The way that Appium organizes itself around this multi-platform model is by means of various “drivers”. This is more or less the same architecture as was first adopted by Selenium/WebDriver, which also utilizes a number of independent “drivers” in order to support the automation of multiple browsers.
There is one Appium driver per underlying automation technology. This almost means one Appium driver per platform (one for iOS, one for Android, etc…), but not quite. This is because some platforms (like Android) have multiple automation technologies that Appium targets to support automation of that platform. Android actually has 3 Appium drivers: one based on UiAutomator, one based on UiAutomator 2, and one based on Espresso.
How Drivers Work?
The driver is arguably the most important concept in all of Appium. It’s ultimately the driver’s responsibility to turn the Appium API (known as the WebDriver Protocol) into automation for a particular platform. For architectural simplicity among other reasons, each individual driver is itself a standalone WebDriver-compatible server (though it doesn’t have all the options the main Appium server does). Drivers themselves can have quite a complex internal architecture, sometimes relying on a whole stack of technologies. Here’s a diagram showing the full stack of technologies involved in the XCUITest driver (the current iOS driver):
The XCUITest driver is made available as part of Appium, and is brought to life whenever someone starts an iOS session. Internally, it spins up another bit of technology known as WebDriverAgent, which is responsible for turning WebDriver protocol commands into XCUITest library calls.
So far there are 11 drivers available. This bit of code defines which strings are allowed to be used as values for the automationName capability. Of course, each driver typically only supports one platform. Here’s a brief description of each of the drivers, by their automationName:
- Appium: this automation name really means “just give me the default driver for the platform I’ve chosen.” It’s not actually a separate driver on its own.
- UiAutomator2: this is the current default Android driver, based on Google’s UiAutomator technology.
- UiAutomator1: this is the older Android driver, based on an older version of UiAutomator.
- XCUITest: this is the current iOS driver, based on Apple’s XCUITest technology.
- YouiEngine: this is a driver produced by You.i Labs, to support automation of apps on many different platforms built using their SDK.
- Espresso: this is the newest Android driver, based on Google’s Espresso technology.
- Tizen: this is a driver produced by Samsung to assist in automation of Xamarin apps built for the Tizen OS.
- Fake: the “fake” driver is used internally by Appium for the purpose of testing, and you shouldn’t need to ever use it.
- Instruments: this is an older iOS driver based on an Apple technology which was removed after iOS 9. Basically, don’t use this.
- Windows: Microsoft put together an Appium-compatible server called WinAppDriver, and this is the driver that connects it up with the main Appium server. You can use this driver to automate Windows apps.
- Mac: this is a driver which enables automation of Mac desktop apps.
As mentioned above, each of these drivers has its own internal architecture, as you can see in this detailed diagram:
You can choose your driver based on the platform and type of application. Mostly, in the current automation world, people are using UiAutomator2 and Espresso for Android platform, XCUITest for iOS platform, WindowsDriver for desktop windows applications and MacDriver for desktop MAC applications. Try to learn more about different automation drivers prior to start the actual development.
Reference: Appium Pro
make it perfect!