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 which 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. Drivers are essentially translators that turn Appium client commands into ... something else---whatever gets the job done on the 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).Within the driver, commands that are received are handled in idiosyncratic ways. They might be passed on to a separate process running as a Java program on an Android device, for example.

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):

There's quite a lot going on! 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.

Many drivers have an architecture like this, though each driver can set up its architecture however it likes, so long as, at the end of the day, it is published as an NPM package that exposes a class which extends Appium's BaseDriver class. This is what makes it possible for a driver to plug easily into Appium!

The Drivers

Well, what drivers are there? It's honestly a bit hard to say exactly, because there exist "unofficial" drivers in addition to the ones that ship with Appium. But if we take a look at the current list in the Appium codebase itself, we can see a fair few:

const AUTOMATION_NAMES = {
  APPIUM: 'Appium',
  UIAUTOMATOR2: 'UiAutomator2',
  UIAUTOMATOR1: 'UiAutomator1',
  XCUITEST: 'XCUITest',
  YOUIENGINE: 'YouiEngine',
  ESPRESSO: 'Espresso',
  TIZEN: 'Tizen',
  FAKE: 'Fake',
  INSTRUMENTS: 'Instruments',
  WINDOWS: 'Windows',
  MAC: 'Mac',
};

These "automation names" are the labels given to the various drivers which Appium knows about. 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 (repo): this is the current default Android driver, based on Google's UiAutomator technology.
• UiAutomator1 (repo): this is the older Android driver, based on an older version of UiAutomator.
• XCUITest (repo): this is the current iOS driver, based on Apple's XCUITest technology.
• YouiEngine (repo): this is a driver produced by You.i Labs, to support automation of apps on many different platforms built using their SDK.
• Espresso (repo): this is the newest Android driver, based on Google's Espresso technology.
• Tizen (repo): 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 (repo): this is an older iOS driver based on an Apple technology which was removed after iOS 9. Basically, don't use this!
• Windows (repo): 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 (repo): 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:

Drivers FAQ

How do I know which driver to use? Well, if you want to automate iOS, Windows, Mac, or Tizen, your choice is simple: use the only driver which currently enables automation of that platform! If you want to use Android, you have the choice of the UiAutomator2 driver or the Espresso driver. It's worth learning a bit about each of these technologies to see which one might better support your use case. The feature set for these drivers is similar but not identical.

Do all the drivers support the same commands in the same way? Yes and no. At a certain fundamental level, we are limited by the automation capabilities provided by the platform vendors. A "tap" on an Android device is the same as the "tap" on an iOS device. But other commands might not work in exactly the same way. As far as possible the Appium team tries to ensure parity of behavior across platforms and drivers.

Can I switch from one driver to another and expect my tests to pass? Yes and no. It all depends on which drivers we're talking about. Part of the benefit of using Appium is that you can change from one automation technology (like UiAutomator2) to another (like Espresso) without throwing away your entire test suite. But you should perform the migration slowly and methodically, making sure that everything is happening as you expect. The Appium team sometimes publishes migration guides for moving from one driver to another; check those out if possible!

Can I make my own driver? Yes! Lots of people have done this, most recently both Jason Huggins and myself (at AppiumConf 2019). But there are others too, like Christian Bromann's hbbtv-driver.

Will anything change with drivers in Appium 2.0? I'm so glad you asked! One unwieldy bit of Appium's driver system is that we have to include drivers as strict dependencies of the Appium server. But we want the drivers to exist in more of a loosely-related ecosystem, where you can pick and choose which drivers you want to use with Appium. This means that you won't need to install the old UiAutomator2 driver and its dependencies if all you are using Appium for is running iOS tests! (Did you know there is a proposal for Appium 2.0's design out there on the Internet?)