13 things I've learned using Appium for Android & iOS Mobile Automation

13 things I've learned using Appium for Android & iOS Mobile Automation

Appium is open source and free

You don't need to spend lots of money on licences on tools such as Ranorex and Katalon Studio.

Test Native, Hybrid and Web Apps

You can test all types of Mobile Apps, not only limited to Native ones.

Based on Selenium

If you're already proficient in Selenium, you will feel at home using Appium as it uses the WebDriver protocol. If you are starting afresh, there might be a learning curve though, especially to understand concepts and best practices.

Android Virtual Device

You can run your tests in an Android Virtual Device if you don't have or want to use a real device. You can install Android Studio which comes by default with a manager that enables you to install virtual devices.

Mac for iOS

To run your tests on iOS though, you need Mac OS.


If you have a cross platform app developed with technologies such as React Native or Xamarin, you want to automate against both Android & iOS. You don't need to own both OSes or devices, but can leverage Platforms (PAAS) such as BrowserStack and SauceLabs. Once you configure your desired capabilities and remote settings, you're good to go.

Multiple Programming Languages

When automating with Appium, you can use your preferred programming language namely:

  • Java
  • Ruby
  • Python
  • NodeJS
  • C#

Programming Principles

With basic programming skills, you can automate your apps; however, good programming principles is much more effective and helpful throughout the project lifecycle. Some concepts I try using:

  • Don't Repeat Yourself (DRY)
  • Object Oriented Programming (Abstraction, Encapsulation, Polymorphism, Inheritance)


When you use logs, it's easier to follow the steps especially when debugging. You don't need to check every test screenshots or videos. You can also use file or cloud loggers to have a trace of the Automation tests.

Config Files

I find using configuration files for values that can change and/or going to change  makes the project cleaner and more manageable. For example, instead of hard coding desired capabilities in the codes, you can have a file to keep those values. Even a non technical person such as a tester can easily change this data whenever required.

Page Object Model

After working on two different Automation projects, I think the Page Object Model (POM) structure is highly productive because of its reusable nature.

For an element such as a Search input on the homepage, I create a homepage class and a public property for this input with a WebElement or MobileElement notation. If I need to operate this element, even in another page, I can do so as it's public. Moreover, if there is any process that repeats, I create a method and call it. For example, SearchForProducts() -> searchElement.sendInput('value'); searchButton.click().

Not hardcoding Element Paths

Instead of hard coding any element xpath, id or className, which can be long and might change if the application is still under development, you can store them externally such as in a YAML, spreadsheet, XML or CSV file. The overall project becomes much cleaner.

Appium Inspector

To interact with any element, you need the path, either a xpath, id or className (among others).

You can use Appium Inspector, both for Android and iOS to get an element path. You can connect it to a real device, a simulated one or use a platform such as BrowserStack.