Migrate Appium Server 1.x to 2.x

     Appium team going to move to Appium server 2.x. Appium 1.x has been around for quite a while and now is the time to move project development forward and to provide an even better automation experience with Appium version 2.x. As of May 2020, Appium 2.0 has been in beta release and is ready for use and testing. You can begin the process of ensuring your test suites, or any other software built on Appium, is compatible with Appium 2.0.

     Appium team announced that after the release of Appium 2.0, they will not be making any feature additions to the Appium 1.x server. They will make the following kinds of updates for 6 months following the release of Appium 2.0 (until March 15, 2022):

  • Feature updates and bug fixes to core drivers (XCUITest, UiAutomator2, Espresso). For the first 6 months of Appium 2.x’s life, the core drivers will be supported on both Appium 1.x and 2.x.
  • Bug fixes to the Appium 1.x server.

Upgrading to Appium 2.x

     Once the 6 months of transition have passed, Appium team will publish new versions of the core drivers that will only be guaranteed to be compatible with Appium 2.x. From that point forward, no features, platform support, or patches will be added to Appium 1.x. Based on the current release schedule, it is likely that Appium 1.22.x will be the last in the set of Appium 1.x releases.

     The changes in Appium 2.0 are not primarily related to changes in automation behaviors for specific platforms. Instead, Appium 2.0 reenvisions Appium as a platform where drivers (code projects that introduce support for automation of a given platform) and plugins (code projects that allow for overriding, altering, extending, or adding behaviors to Appium) can be easily created and shared. Following are breaking changes to how Appium is installed, how drivers and various features are managed, and protocol support:

 Installing drivers during setup

     When you installed Appium 1.x, all available drivers would be installed at the same time as the main Appium server. This is no longer the case. Simply installing Appium 2.0 (e.g., by npm install -g appium@next), will install the Appium server only, but no drivers. To install drivers, you must instead use the new Appium extension CLI. For example, to install the latest versions of the XCUITest and UiAutomator2 drivers, after installing Appium you would run the following commands:

appium driver install xcuitest
appium driver install uiautomator2

     At this point, the drivers are installed and ready. There’s a lot more can do with this CLI. If you’re running in a CI environment or want to install Appium along with some drivers all in one step, you can do so using some special flags during install, for example:

npm install -g appium --drivers=xcuitest,uiautomator2

     The above command will install both xcuitest and uiautomtor2 drivers along with Appium server installation.

 Driver specific command-line options

     With Appium 1.x, command-line options specific to particular drivers were all hosted on the main Appium server. So, for example, –chromedriver-executable was a CLI parameter you could use with Appium to set the location of a specific Chromedriver version. With Appium 2.x, all driver and platform specific CLI params have been moved to the drivers themselves. To access them, we use a single CLI param called –driver-args. You can construct an object with parameters for one or more drivers by their name to specify the options for drivers. Below example will set the chromedriver binary path to the uiautomator2 driver,

appium --driver-args='{"uiautomator2": {"chromedriverExecutable": "/path/to/chromedriver/binary"}}'
Driver updates

     With Appium 1.x, to get updates to the iOS or Android drivers, you’d simply wait for those updates to be rolled into a new release of Appium, and then update your Appium version. With Appium 2.x, the Appium server and the Appium drivers are versioned and released separately. This means that drivers can be on their own releases and that you can get driver updates as they happen, rather than waiting for a new Appium server release. Following CLI command will help you to check for driver updates:

appium driver list --updates

     If any updates are available, you can then run the update command for any given driver as follows:

appium driver update xcuitest

     To update the Appium server itself, you do the same thing as in the past: npm install -g appium. Now, installing new versions of the Appium server will leave your drivers intact, so the whole process will be much more quick.

Protocol changes

     Appium’s API is based on the W3C WebDriver Protocol, and it has supported this protocol for years. Before the W3C WebDriver Protocol was designed as a web standard, several other protocols were used for both Selenium and Appium. These protocols were the JSONWP (JSON Wire Protocol) and (M)JSONWP (Mobile JSON Wire Protocol). The W3C Protocol differs from the (M)JSONWP protocols in a few small ways. Up until Appium 2.0, Appium supported both protocols, so that older Selenium/Appium clients could still communicate with newer Appium servers. Moving forward, support for older protocols will be removed. May be they will re-design the client libraries for Appium 2.x to work with new protocols.

Capabilities changes

     One significant difference between old and new protocols is in the format of capabilities. Previously called desired capabilities, and now called simply capabilities. There is now a requirement for a so-called vendor prefix on any non-standard capabilities. The list of standard capabilities is given in the WebDriver Protocol spec, and includes a few commonly used capabilities such as browserName and platformName. These standard capabilities continue to be used as-is. All other capabilities must include a vendor prefix in their name. A vendor prefix is a string followed by a colon, such as appium:. Following are some examples,


     This requirement may or may not be a breaking change for your test suites when targeting Appium 2.0. If you are using an updated Appium client, the client will add the appium: prefix for you on all necessary capabilities. So simply be aware that if you get any messages to the effect that your capabilities lack a vendor prefix, this is how you solve that problem.

     Appium team also introduced the option of wrapping up all Appium-related capabilities into one object capability, appium:options. You can bundle together anything that you would normally put an appium: prefix on into this one capability. Following is an example of how you might start an iOS session on the Safari browser using appium:options:

    "platformName": "iOS",
    "browserName": "Safari",
    "appium:options": {
        "platformVersion": "14.4",
        "deviceName": "iPhone 11",
        "automationName": "XCUITest"
Removed commands

     Commands which were a part of the old JSON Wire Protocol and not a part of the W3C Protocol are no longer available. If you use a modern Appium or Selenium client, you should no longer have access to these anyway, so any breaking changes should appear on the client side first and foremost.

Image analysis features moved to plugin

     One of the design goals for Appium 2.0 is to migrate non-core features into special extensions called plugins. This allows automation engineers to opt into features which require extra time to download or extra system setup. The various image-related features of Appium (image comparison, finding elements by image, etc…) have been moved into an officially supported plugin called images. If you use these image-related methods, to continue accessing them you will need to do two things,

  • Install the plugin using the command appium plugin install images
  • Ensure you start the Appium server with access to run the plugin by including it in the list of plugins designated on the command line, for example: appium –plugins=images
Removed drivers

     The old iOS and Android (UiAutomator 1) drivers and related tools (for eample: authorize-ios) have been removed. They haven’t been relevant for many years anyway.

Appium Inspector split out from Appium Desktop

     The inspecting portion of Appium Desktop has been moved to its own app, Appium Inspector. It’s fully compatible with Appium 2.0 servers and simply download it and run it on its own. You no longer need the GUI Appium Desktop server to inspect apps.

     You can also now use the Appium Inspector without downloading anything, by visiting Appium Inspector Web Version. To test against local servers, you’ll need to start the server with flag –allow-cors. So that the browser-based version of Appium Inspector can access your Appium server to start sessions. You can start the Appium session as follows to inspect the element using Appium Inspector Web Version,

appium --allow-cors

     I hope you got a high level idea prior the migration from Appium 1.x to Appium 2.x.

Ref: Appium

make it perfect!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Create a website or blog at WordPress.com

Up ↑

%d bloggers like this: