Skip to content

One of the requirements of using Appium for mobile test automation is to start the Appium server in the background so that it can listen to the requests from the mobile app under test. And there are multiple ways that we can install and start the Appium server in the background.

While running Appium tests from a local machine, we have to launch the Appium server on a specific port and update the desired capabilities to point the server running locally. But there should be a better way to handle these and avoid extra work on desired capabilities. Fortunately, Bitbar provides the means to run Appium client-side as well as cloud-side. In this post, we will compare the client side and server side Appium and see both sides of the coin.

Client-Side vs. Cloud-Side Appium

With Client-side Appium, we need to configure Bitbar specific desired capabilities to execute the test on the Bitbar real device cloud from the local machine. However, the Appium server and the real devices are hosted in the cloud. You can read more about the client side Appium here.

In the case of the Cloud-Side Appium, we just need to upload our application and Appium tests, and we don’t need to configure the desired capabilities. In the cloud-side Appium, we will get parallel testing and device selection from the device group. This is the diagram showing the critical difference between Client-Side and Cloud-Side Appium.

client-side vs cloud-side execution bitbar

There is a great slide share document explaining the difference between the client-side and cloud-side Appium here.

Pros of Client-Side Appium

Either way of Appium execution will anyway achieve your end goal to verify your defined test steps. Let’s first see some advantages of Client-Side Appium.

Local & Cloud Execution

One of the critical benefits of Appium Client-Side Execution is the ability to launch the tests from developers’ local machine. This will allow quick testing of new features that are under development straight from the developers’ machine. We can trigger Appium tests on real devices by updating the Appium server address from the local machine to the Bitbar Cloud hub. This will allows us to unleash the test run from any computer.

Ability to Configure the Devices of Choice

With Client-Side Appium, developers and testers can configure the devices of their own choice as client-side execution enables us to configure the desired capabilities and devices from the code.

Upload Local Test Results onto the Cloud

With Client-Side Appium, once the execution of test suites is finished, you can get access to the video recording of the test directly from Bitbar Cloud. Additionally,  you can upload .xml files to Bitbar Cloud and view test steps in a more readable way.

Cons of Client-Side Appium

In a way, Client-Side Appium is not wrong to help teams get started with Appium test automation at the early stage. However, there are a few critical drawbacks of Client-Side Appium that might be overlooked and may have a substantial negative impact on business success.

Flaky Tests

Client-Side Appium allows developers to start the Appium server from their local machines, so test scripts need to establish the connection between the local Appium and the devices. As the tests are so dependent on the network connection with the local machine, they can become very flaky. The flaky tests cause loss of trust and waste of developer time in the investigation if the failure occurs because of the network or the test itself.

Slow Tests

While using Client-Side Appium, there must be a connection between the local machine and the devices in the cloud. All the test files need to be transferred over the internet to the target devices for test execution, and when the tests are finished, the test results will also be sent back to the local machine through HTTP. This is really not the agile approach as the transfer of test files and results is dependent on the speed of the internet.

When the internet speed suffers, the whole team might be just waiting for the test results without being able to get instant feedback. The slowness, in general, affects the team productivity and waste of time.

Extra Work on Desired Capabilities

Desired capabilities are a set of keys and values sent to the Appium server and inform the server about the configuration of the automation session. When running Appium tests on the client side, you will need to configure those desired capabilities so that the test is ready for execution on Bitbar Cloud.

When you want to execute the Appium test on a specific device on the cloud or change target device from Android to iOS, you’ll need to edit some desired capabilities to get tests successfully executed every single time.

No Parallelism – One Device at a Time

Due to the nature of Client-Side Appium, here comes one of the most significant disadvantages – executing tests on only one device at a time, unless you have the luxury of having multiple terminals/VMs for parallel connections to the devices in the cloud.

It might sound ok if you run Appium tests only to verify whether the new test works on any single device, but it’s undoubtedly counterproductive when you want to run these tests on a large number of real devices with Client-Side Appium.

Pros of Cloud-Side Appium

As the default approach of test execution, though Client-Side Appium does have its merits, the drawbacks are quite significant. And there’s a much better way, Cloud-Side Appium.

Zero Configuration

Unlike Client-Side Appium with which we have to continually configure desired capabilities of target devices to enable test execution, there is no need for that when using Cloud-Side Appium. Once your test script is ready, just select the devices you want to run your tests on Bitbar Cloud. The rest is taken care of by our platform. This reduces the hassle of configurations and potential errors in the configuration.

Parallel Testing

With the Cloud-Side Appium, we can execute tests on hundreds of real devices in parallel at the same time. All the configurations that are needed to run parallel tests will be handled by Bitbar Cloud under the hood. Appium servers get started under the hood and attached to selected target devices for parallel execution.

Faster & More Stable Tests

As stated above, one of the leading causes of flaky tests with Client-Side Appium is that all the test files and results would need to go through multiple layers of the network. That’s not the case for Server-Side Appium, as all the test files are uploaded to Bitbar Cloud first and test execution happens on the server. It’s considerably faster than the Client-Side execution approach to get more reliable test results.


With Cloud-Side Appium, the monitoring of the tests become so painless as we can see test execution in real time and test results in terms of screenshots quickly.

Cons of Cloud-Side Appium

There are not many cons of Cloud-Side Appium as we get speed and stability. One possible disadvantage could be

Hard to Integrate with Other Local Systems 

The only potential drawback for the Cloud-Side Appium could be that if you have tests integrated with other local systems, it will become tough to trigger the test execution over on the server side and trigger the following tasks on your local machines.

Which One to Use?

It’s clear that the Cloud-Side Appium approach is a way better approach than the Client-Side Appium approach. Not only can you enjoy the benefits of parallel device testing and alleviate the pain of maintaining scripts for executing tests, but also it dramatically improves team productivity and trustworthiness of tests that Client-Side Appium couldn’t provide.

Bitbar offers both ways of executing Appium tests. Though Client-Side Appium is still beneficial for quick sanity tests, Cloud-side Appium is highly recommended for larger regression test suites to speed up and scale your mobile app testing.

Shashikant Jagtap

Mobile DevOps Engineer