• Appium is an open-source tool for automating native, mobile web, and hybrid applications on iOS mobile, Android mobile, and Windows desktop platforms. 
  • Native apps are those written using the iOS, Android, or Windows SDKs. 
  • Mobile web apps are web apps accessed using a mobile browser (Appium supports Safari on iOS and Chrome or the built-in ‘Browser’ app on Android). 
  • Hybrid apps have a wrapper around a “webview” — a native control that enables interaction with web content. Projects like Apache Cordova or Phonegap make it easy to build apps using web technologies that are then bundled into a native wrapper, creating a hybrid app.
  • Appium is “cross-platform”: it allows you to write tests against multiple platforms (iOS, Android, Windows), using the same API. This enables code reuse between iOS, Android, and Windows testsuites.

Appium Philosophy

Appium was designed to meet mobile automation needs according to a philosophy outlined by the following four tenets:

  1. You shouldn’t have to recompile your app or modify it in any way in order to automate it.
  2. You shouldn’t be locked into a specific language or framework to write and run your tests.
  3. A mobile automation framework shouldn’t reinvent the wheel when it comes to automation APIs.
  4. A mobile automation framework should be open source, in spirit and practice as well as in name!

The vendor-provided frameworks we use are:

Types of Mobile Applications

Appium has the ability to deal with all sorts of applications. Let’s understand the different types of applications.

Native Applications

  • Applications that are developed, keeping a certain platform in mind are called native applications.
  • Native applications are developed using specific software development kits and tend to be performance focused. 
  • Native mobiles application are platform specific different app for android and ios
  • Native apps are fast like calender,calculator, camera
  • Easy to automate
  • Native apps are generally the way to go if the development budget is not an issue. 
  • Some advantages of native applications are as follows –
    • Excellent performance
    • They generally tend to look refined and polished
    • Native applications seamlessly integrate with device hardware
    • Most native applications have an intuitive UI/UX

Some examples of native applications include Spotify, Snapchat, Pinterest, Skype.

Web Applications

  • These kinds of applications used to be really famous until the concept of native applications came along. 
  • Web applications as the name suggests, run on a browser.
  • Two type of web application adaptive(features for mobile only) and responsive
  • Completely slower

Below is a list of advantages of web applications –

  • Lower development cost
  • Easier to maintain
  • Easy to automate
  • Web-apps don’t need to be approved by application marketplaces
  • No installation or user updates

Examples of successful web applications include Ali Express, Flipkart Lite and Washington Post.

Hybrid Applications

  • Hybrid applications merge the best of native and web applications. 
  • While these applications can be downloaded from the play store and can also access all the features of the device; they are in actuality a web application on the inside. 
  • They are developed using simplistic web-development languages like HTML and CSS. 
  • This allows them to run on any platform.
  • Tricky to automate
  • Need to enable debug mode in the android phone

Below is a list of advantages of hybrid applications –

  • They only have one codebase to manage
  • App development doesn’t take too long
  • Easy to scale to another platform
  • Access to complete device features just like a native app
  • Poor user experience as compared to native

Some example of hybrid apps are OLA, Basecamp, Instagram, Yelp etc

Appium Concepts

Client/Server Architecture

  • Appium is at its heart a webserver that exposes a REST API. 
  • It receives connections from a client, listens for commands, executes those commands on a mobile device, and responds with an HTTP response representing the result of the command execution.
  • The fact that we have a client/server architecture opens up a lot of possibilities: we can write our test code in any language that has a http client API, but it is easier to use one of the Appium client libraries. 

Session

  • Automation is always performed in the context of a session. 
  • Clients initiate a session with a server in ways specific to each library, but they all end up sending a POST /session request to the server, with a JSON object called the ‘desired capabilities’ object.

Desired Capabilities

  • Desired capabilities are a set of keys and values (i.e., a map or hash) sent to the Appium server to tell the server what kind of automation session we’re interested in starting up. 
  • There are also various capabilities which can modify the behavior of the server during automation. For example, we might set the platformName capability to iOS to tell Appium that we want an iOS session, rather than an Android or Windows one. 

Appium Server

Appium is a server written in Node.js. It can be built and installed from source or installed directly from NPM:

Appium Clients

There are client libraries (in Java, Ruby, Python, PHP, JavaScript, and C#) which support Appium’s extensions to the WebDriver protocol.

Appium Desktop

There is a GUI wrapper around the Appium server that can be downloaded for any platform. It comes bundled with everything required to run the Appium server, so you don’t need to worry about Node. It also comes with an Inspector, which enables you to check out the hierarchy of your app. This can come in handy when writing tests.

Limitation of Appium

  • iOS automation with local Appium server requires a Mac
  • Maintaining local Appium server lab requires additional resources
  • Documentation is limited or some times too technical
  • Changes to XCTest framework often breaks Appium