Appium Reviews

Automated testing of mobile applications — both native, hybrid, and mobile web apps — across Android and iOS platforms.

No licensing cost. Speeds up regression tests,supports parallel execution across devices/platforms. Used single codebase for both Android and ios. Easily integrates with CI/CD pipelines (e.g., Jenkins, GitHub Actions).Supports multiple programming languages(e.g., TestNG, Cucumber).

Emulates Android and iOS devices effectively. The interface is user-friendly, which is beneficial for users, even for those who are new to it.

Uses single codebase for both Android and ios. Easily integrates with CI/CD pipelines (e.g., Jenkins, GitHub Actions).Supports multiple programming languages(e.g., TestNG, Cucumber).

Initial setup for Appium (especially for iOS) is not beginner-friendly.Consumes too much of your host machine's resources, potentially slowing down the machine.Appium Inspector often lacks deep insight or crashes with certain app builds.

Improve test flakiness by intelligently selecting robust self-healing locators,simplified installers, better documentation, GUI-based config management,smart wait mechanisms and better failure logs.

Since 2017 September

At times, Appium consumes too much of your host machine's resources, causing the machine to slow down. I would rate its stability at four out of five.

Can be extended with AI-based testing tools (e.g., Applitools for visual testing).Supports custom plugins and can evolve with organization needs.

Have not availed customer support

Positive

Used Selendroid before, that has support for native and hybrid apps in Java (via Selenium WebDriver) only. Has no support for cross browser testing.

QTP/UFT One needed license for mobile testing.

The installation part of Appium is somewhat clumsy, requiring numerous dependencies and configurations.

In-house

Faster time to market,speeds up automated repetitive tests.

Appium is open source, so there is no cost involved. This is a significant advantage over commercial tools like UFT, which requires purchasing license.

Cross browser, device and multiple  programming language support. CI/CD integration, scalability, and cloud testing.

Appium runs on Node.js and supports frequently used programming or scripting languages like Java, JavaScript, and Python. It is advisable to give it a try since it is free and can handle a variety of programming languages. It is suitable for both beginners and seasoned testers.

I'd rate the solution eight out of ten.

I use it to make tests for Android applications.

What I like about Appium right now is that it's like Cypress in the sense that I can get to the new DOM of the application and select the components and create the functions to test the components in the way I want them to be tested. That's why I like it right now.

The initial setup and configuration of an Appium project is tedious and challenging.

I have been using it for a month. 

It runs fine.

Configuring the project to be used in Appium is a little bit tedious. But when it's already configured and you already connect the application to the framework, it's better. The first part, configuring the project to use with Appium, is not that easy.

It needs some experience, or at least some time to get adjusted to the tool.

The initial setup took about a week.

I just used the free open-source version.

My recommendation depends on the project someone is trying to test because it's a complex framework, and unless you already know what you want to test, I wouldn't go with Appium on the first try. 

If you know what you want to test and you know you need some particulars, like particular integration or functions, I wouldn't go first with Appium. If I know what I want, then I will only go with Appium.

Overall, I would rate the solution a six out of ten. 

We're a large enterprise, and my project team consists of about 30 automation code developers. Everyone on the team is using Appium. Appium automates mobile browsers and applications. I use Appium to launch iOS and Android mobile applications with the package name and launch activity.  After that, we do some operations on the applications. 

For example,  we enter some text into the fields to verify if we've entered the wrong set of inputs. Some boxes will be limited to text only, and we'll get an error if we enter special characters. Appium helps us check all those things. We can also check the UI server to test if the button navigates to the next page or not. 

The most valuable feature is that it's easy to launch applications. Appium has everything that Selenium has. So many good tools support Appium. We can take some Excel sheets and use them to fill out the text box that's in there. We can also take screenshots of failures.

Image recognition could be improved. We have some images in our mobile applications. It should be able to run from the cloud, so we can automate the catcher. 

We need to launch the Appium server when we want to connect the mobile application with Appium. Sometimes, the Appium server won't connect with the mobile application because of some socket issues, so network connectivity between applications and the Appium server could be improved.

I have been using Appium for five years.

Appium is a highly stable product for our purposes.

We can scale Appium.

I believe Appium doesn't have dedicated technical support because it is an open-source tool. When I have issues, I find solutions on the forum. 

We decided to use Appium because it's an open-source solution that supports so many languages, including Java, Adobe, C#, and Python. That's why so many DevOps and IT people prefer it.

I rate Appium eight out of 10 for ease of setup. When I first began using the product, I would rate it as six out of 10. Appium is challenging to set up for iOS and Android, but we can manage iOS automation on the Mac from Macintosh Missions. In Missions, we need to open our Appium project on the next board and create something like a bundle diary. The bundle diary from Appium doesn't work for outputs, so it should not work for our daily routine. We need to change the bundle ID and build the iPhone application. 

There are two ways to set it up. You can update the Appium server for HD and need to do programming and training. It will come in after 30 seconds or more. 

Appium is completely free.

I rate Appium nine out of 10. It's one of the most stable solutions for mobile automation. It inherited a lot of functionality from Selenium, a popular tool for automation. We can write advanced code and achieve every mobile app channel using Appium. 

If you want to use Appium faster, you need to do things right during installation.  We should be aware of the programming language. We need to use some framework to make our life easier while using Appium.

We use Appium for certain test cases with respect to mobile device testing. We migrate those test cases to our automation tool.

I like that Appium is an opensource tool. I also like it's cross-platform flexibility.

Appium provides a record-and-play option, and the commands are the same as those that Selenium uses. So a person who has some exposure to Selenium will be able to write a piece of code in Appium.

The challenging part with Appium is that installation can be a bit tricky. It can be  challenging to set up in Android versus iOS environments.

Appium has some limitations in terms of writing code using simulators and online cloud devices. I faced challenges with native based scenarios, battery turn out percentage, battery charging percentage, and memory capacity.

The other challenge I faced involved codes changing from device to device. For example, the piece of code that works in iOS version 10.1 won't work in iOS version 6.0.

In upcoming releases, if they can reduce some more of the dependencies like SDK, UIAutomator, etc., it would be great. That is, I'd like to see a consolidated package or bundle release that is much more user-friendly.

I've been using it for four plus years. I have experience with both on-premises and cloud deployments.

Appium is stable as per my experience, but sometimes there are issues due to command balance. Some methods are supported in one version but not in another. However, this can be overcome with alternate solutions or add-on tools.

Scalability-wise, if you are going to run in a single machine, then you can scale it out. However, if you want to do a distributed execution for an iOS device, it can be pretty difficult.

Solution-wise, I will rate technical support at eight out of ten, but for response time, SLA-wise, I would give them a six out of ten.

Appium is a two-tier application, so you have to be very careful while doing the setup.

There are multiple steps involved, and if you miss a single step, your server will not launch, and you will not able to inspect those elements.

The initial setup is not hard, but it's not easy either. On a scale from one to five with five being easy and one being hard, I'd rate Appium's initial setup at two.

Deployment time-wise, for Android it can take three to four hours and for iOS about eight hours.

It's completely 100% free, and there are no hidden fees.

I would suggest checking whether you have knowledge of the programming language. You must also understand the flow, the architecture, and how the application that you're going to test will behave, whether it's a native application, hybrid application, or web-based application. Then, based on the nature of the application and the technical expertise you can decide whether to use Appium.

You have to be very careful while doing the installation. There are about 40 to 45 steps involved in the set up of Appium for Android devices and approximately 60 to 65 steps for iOS devices.

Data transformation can be tricky, but transferring of the controls is very easy. Predefined tools and methods are available, and you can import those libraries and use them as per your requirements.

Overall, I would give Appium an eight out of ten.

Our company uses the solution's library to test and automate mobile devices including Android and iOS. 

The solution provides one roof or framework for both iOS and Android code bases. 

The library is extensive so the driver interacts with most functions or actions on mobile devices such as tap, swipe up, write down, touch actions, and opening or closing sessions. 

The solution needs to support more actions such as locking a phone or adding a fingerprint. 

Some action methods have been combined to one touch action but this should revert back for easier customization. 

The user interface needs improvement because there are issues when setting up environment variables. 

Some actions are not supported across languages such as JavaScript, Python, and C# so documentation, examples, and boilerplates are needed. 

I have been using the solution for seven years.

The solution is stable. 

The solution is not designed for scalability but can be scaled via cloud services or a local device farm. 

We currently have two users but may add more in the future. 

The solution is open source so does not offer technical support. 

If you have issues, you can Google answers or ask developers direct questions through their repository. Forums are also available for support. 

I have used multiple automation frameworks including Nightwatch.js but most were integrated with the solution's libraries. 

The setup is a bit complex for use with iOS. 

Even Android setups require a couple of steps that need to be completed each time. 

We implemented the solution in-house and it only took a few minutes.  

The solution is an open source library so just needs to be added to the package list. Anyone can install it on their system which also happens in your CI/CD. 

The solution is open source so it is free. 

Almost 80% of the market uses the solution and we did not evaluate other options. 

The solution is a fit when you need both iOS and Android frameworks because it combines them under one roof.

If you only test on a specific platform, you can use base libraries or drivers. For example iOS works on XCUI drivers and Android works on UiAutomator. 

The solution is the go-to library right now with few alternatives. 

I rate the solution a seven out of ten. 

We use Appium to test our native applications for iOS and Android. The solution is deployed locally and integrated into our instance of GitHub Actions for CI/CD functionality, so it's a hybrid deployment. 

Using Appium with React Native allows us to reuse our tests for both Android and iOS. If we had to use one tool for Android and another for iOS, we would need two repositories, two tests, and a lot more coding for us to do. I think React Native is the only real solution available nowadays for black box testing the way we prefer to do it.

We develop apps using the React Native framework, and Appium integrates well for testing those apps. The Appium automation framework also has good integration with GitHub Actions and plenty of other tools and frameworks, including BrowserStack. 

Appium also offers plenty of testing interactions, including swipes and other actions. It provides more interactions compared to other solutions like Selenium HQ, which is another tool we work with.

Appium Inspector is another excellent feature that provides us with a lot of information when dealing with app elements. One of our uses for this is determining which selectors are faster, as we want our apps to be as fast as possible. 

We previously worked with native applications, and there weren't any good mobile app testing tools. We started working with React Native, which works well with Appium, but it would be good to see better integration; the way elements are displayed can be messy. React Native is very popular nowadays, so it's essential to have that compatibility.

Appium doesn't recognize IDs placed by our developers on nested elements when we use React Native for iOS; it just sees the whole page and one element. We use coordinates to get around this, but it isn't the best system, and nobody in the community has been able to help us.

iOS is also strict in general when it comes to signatures and developer accounts, which creates additional headaches for iOS testing compared to Android. It would be great to see a more streamlined setup for iOS, but that might be more of an Apple issue than an Appium one. 

We have been using the solution for about four years. 

The solution is relatively stable, but sometimes tests can become flaky. This could be because of Appium, or due to a cloud-related issue, it isn't exactly clear. It's more stable than it was four years ago, so the product has improved, but there is still room for better stability. 

The solution is scalable. Once it's installed on the machines or in the cloud, everyone can run it and I don't think it matters how many staff members use it. We have nine end users in our organization. 

Appium is an open-source solution so there isn't a number to call for technical support. However, there is a large user community, so it's easy to find help for issues. 

The initial setup is very straightforward; it's just a download with a desktop installation. Setup time depends on your internet, but I would say it takes minutes.

Appium is open source; we can use it for free.

We looked at Espresso and XCUITest, which are native testing apps for Android and iOS, respectively, but we can't use those for both in React Native. We carried out a POC for Appium, and there were no viable alternatives. It allows us to use one tool and one repository for both mobile operating systems.

I would rate the solution eight out of ten. 

Appium is a great tool, and I recommend it. Working with iOS requires patience, and setup can be somewhat demanding, but there are no such problems with Android. Overall, the solution does what we need it to do.

Our use case for Appium is writing end-to-end tests for mobile applications. We also use it for some data extraction for an end-to-end user desk.

For the particular use case we used Appium for, we felt that it served our purpose completely, and we haven't had any issues with the Python Client for Appium. Appium has been a good solution for us.

I haven't explored other solutions in this particular area, but what I like best about Appium is the fact that it shares functions with Selenium. The extension of Selenium functions allows me to use all of the methods that exist in that domain, and it just makes it simpler for me. I've been using Selenium for some time as well, so using Appium just seems like a natural fit for me.

What needs improvement in Appium is its documentation. It needs to give more context on the libraries that Appium is using under the hood. For example, my team is using Appium for Android automation, and a lot of times, I feel that there's functionality that's available through the Appium interface, that exists within the UIAutomator, but there aren't a lot of useful or helpful resources on the internet to find that information, so it would be good to have some linkage with the underlying platform itself.

Another room for improvement in Appium is that it's buggy sometimes. For example, at times, there's a bug in the inspector application that doesn't allow me to save my desired capability set, so it would be nice to get that bug fixed, but overall, Appium is a good tool.

The Touch Actions functionality in Appium also needs improvement. For example, if I want to initiate a scroll on the device that I'm running Appium on, sometimes Swipe works, but in other situations, I have to explicitly use action chains, so I'm not too sure what's the better approach.

What I'd like to see in the next version of Appium is a more intelligent and more intuitive AppiumLibrary, in terms of identifying menus and scroll bars, etc., because right now, I'm unsure if I have to do a lot of export reversals to get to the elements I'm looking for. It would be nice to have some functionality built in, which would allow me to easily get those exports.

I've been using Appium for almost two and a half years now.

Appium is stable so far, performance-wise. I never had any performance issues with Appium scripts, and I could potentially do as many Appium programs as I want, and I'd only be limited by the compute capacity of the particular machine that I'm running it on, so no issues there.

Appium has decent scalability, and I've primarily used the Appium-Python-Client. What the Appium team could look into would be the possibility of running Appium in a cluster because currently, there's not a lot of in-depth documentation on how to do it.

For example, the way Selenium Hub works with Kubernetes, if Appium can have that functionality of working with Kubernetes, then that would ensure the greatest scalability for Appium.

I've never had to reach out to the Appium technical support team. I'm not even aware of the support channels for Appium, but I haven't had to reach out ever.

I wasn't sure of what other solutions existed out there. I just came across Appium, and I thought that Appium suits my use case, and it's open source, so that helps.

The initial setup for Appium wasn't as straightforward. I was an individual contributor that pitched this idea to my organization about using Appium, and I was solely responsible for researching it, writing code, then deploying it. It wasn't too straightforward, but in the end, I was able to get it done.

I did the deployment of Appium all by myself.

There were implicit monetary benefits that have come from our use of Appium, so ROI wasn't explicit. We got cost savings, reductions in downtime, stability, etc., from using Appium, which translates to ROI.

I'm unsure if there's any cost associated with Appium. I got the free package which includes the server GUI application and the inspector application, and it was free to download, and that's all I need to get my work done.

I'm not aware of any additional costs associated with the tool. Essentially, if you want to run Appium in a production environment, you'll need to hook it up with an emulation service, and though that's outside the scope, that has to tie and deliver the entire solution.

I'm using the Appium-Python-Client version 2.1.2.

In my company, between four to five people use Appium.

The number of people required to maintain Appium depends on the number of tests you've written. In my company, a single person can maintain it.

Right now, Appium is being used pretty extensively within the company. My team runs and tests four to five different applications, and that list will be extended, so usage of Appium will go up in the future. It's not going to go down.

The advice I would give to anyone on Appium for the first time is to look into the underlying automation, for example, the UIAutomator for testing. I would urge you to also look into the different functionalities offered by the base automation and essentially use those features provided by the base automation within that context because that's going to give you the biggest branch of data.

My rating for Appium is seven out of ten, based on the work I'm doing on it.

My company is a customer of Appium.

We primarily use the solution for UI validation of mobile applications. It's a mobile development platform. We have an application where we have to test the front end and how it is cloning.

It's easy to connect the product. Within a single command, we can easily connect to the device. The connectivity is just that easy.

We get a list that shows all devices that are connected to the system.

It is a very easy initial setup.

Support-wise, it could be better. Whenever we get some issues, it may take some time. I'd like them to be more responsive. 

There's not too much public documentation or information. If we Google information or something else regarding the Appium, there won't be much compared to Selenium. Selenium is also open-source. Appium details are limited.

It is difficult to understand. Recently, there were major changes in Appium. Understanding those changes, was a bit difficult. There just wasn't enough transparency.

I've been using the solution for one and a half years. 

The solution is pretty stable. That said, either from the application side or the Appium side, sometimes, I get some error that is not correct. Even if the application is open, sometimes it throws some error, however, maybe it is from the emulator side. I'm not sure. 

If I run the same test case, and in the same execution, I don't see that error again. It's random, yet may be from our side. I don't think it's from Appium. However, I'm not sure. 

The solution is scalable. The capacity is very good. 

We have three QAs using the product.

Technical support is not as responsive as we would like them to be. They often are late to reply. Sometimes to topic diverts towards something else. It's open-source, which means support is always a bit of an issue. 

Neutral

We also have used Selenium, which has more information available. Selenium is also open-source. Both are pretty similar. 

The solution is very easy to set up. It's not an issue at all. It took one or two days to connect the emulators. It was pretty simple and straightforward. 

I'd rate the initial setup at a five out of five in terms of ease of deployment. 

This is an open-source tool.

We are end-users. We tend to use the solution on a weekly basis.

I'd rate the solution at an eight out of ten. 

I'm using Appium for the automation of applications on Android and iOS.

Appium has improved my company because it makes it easier to connect devices to automation scripts because the library is easy to use. You can also detect mobile elements faster in both Android and iOS.

The best feature of Appium is that it allows you to inspect the element. With the Appium Inspector, you don't have to install another application to do the inspection. I also like that Appium has Android device connectivity. Currently, most people use Appium as automation software, and I haven't found any other tool that's more powerful than Appium.

I rarely use Appium nowadays because I'm now at the managerial level, but the last time I used it, whenever I selected and clicked on an element, Appium was very slow. I tried to debug it, but I still couldn't find the problem, so this is an area for improvement in the solution.

Another area for improvement lies with the connector and server. For example, the effort to get into the local machine sometimes causes the emulator to become slow, which then leads to failure in testing, and this is the usual issue I've encountered from Appium.

An additional feature I'd like added to Appium in its next release is being able to do automation in iOS without using XPath and the name of the element. In Xcode, you can use previous UI tests for detecting elements, but in Appium, you have to use Xpath and the element name instead of being able to directly put the X-UiPath, which is what you can do in Xcode. In iOS as well, sometimes the element doesn't have a name or a path. Sometimes, there's also no element.

I've been using Appium for more than four years.

Appium is a solution that's quite stable.

Appium is a scalable solution. A lot of devices are connected to Appium, and the solution runs every day for integration testing, with new test cases added daily. Appium keeps growing, and it's scalable.

A separate team works with the Appium technical support team whenever there's an issue, so I have no experience contacting support.

I've only used Appium, and I haven't found a solution that's as good as Appium.

Setting up Appium is quite easy because a lot of documentation can be found on the internet. From setup to deployment, it only takes less than one hour if there's no problem, but usually, the problem is on the environment side, not in Appium itself. Sometimes the emulator doesn't connect to Appium, and sometimes there's a broken dependency, for example, Node.js isn't supported, or a certain percentage of Node.js must be used.

As far as I know, Appium is a free solution. It's not for commercial use.

I'm using the latest version of Appium.

My current company has a lot of programmers, so I don't have the exact figure on how many people use Appium, but in my previous company, two people deployed the solution on the cloud server.

The only time maintenance is required in Appium is when there's a new update, and my team would first ask about how stable the new version is, then that's the time the team upgrades the version of Appium.

In the AP department, seventy to eighty people use the solution. The users only create the automation path and then test it on the local machines with Appium, then deploy it on the cloud server. The AP users aren't in charge of maintaining Appium.

I'd recommend the solution to other users. Most of the companies here in Indonesia use Appium, and on a scale of one to ten, my rating for Appium is nine out of ten.

My company is a customer of Appium.

It's normally used to test mobile applications, and to interact with some power applications. It's mainly for mobile testing applications?

I like the app inspector. It's quite a good and useful tool for us. I like that we can use it almost out of the box. 

It works well on Android. 

The solution is stable.

It's very scalable. 

The solution is free to use. 

I'm facing a lot of issues with my new juniors when they set up Appium for iOS. For Android, it's easy, however, for iOS to interact with it on iPhones or something. It requires some additional libraries and some additional installation. Sometimes it's not working. While Android works well, iOS continues to be an issue. 

There are a lot of issues on GitHub discussions and Stack Overflow, et cetera, and it's still not resolved. When we use Appium Inspector and just Appium, we are not able to inspect nest elements. Half of the elements are nested. Especially for React Native, it's not visible in Inspector, and we cannot interact with this element. We need some bug fixes for nested elements. 

We'd like a one-button click where you hit it, and everything is automatically installed. 

I've used the solution for three or four years, maybe less. 

Generally, I'm not facing any issues with stability, so I am quite satisfied. There are no bugs or glitches. It doesn't crash or freeze. 

I'm not facing any issues with scalability. It's not a problem to expand. 

We have a team of ten using the solution right now. We use it on a daily basis. We have daily test runs, using Appium, and have test cases to update, to add on a daily basis.

We have zero direct interactions with Appium. If we need help with something, we just use some resources from the internet or some documentation. Aside from eh issues we've had with nested elements, this has always been enough for troubleshooting. 

I have no experience using other automation tools for our devices. We only use Appium.

It's not difficult to set up and deploy. However, it does take time. We use Macbooks. We don't use Windows. It's more complicated to set up on iOS than on Windows. It can take two to four hours to configure everything once you have it deployed. For example, if you have ten devices, the time is two to four hours each, so it can take a while. 

I'd rate the solution two or three out of five in terms of ease of deployment. 

This is a free tool. 

Based on the issues we've had, I'd rate the solution six out of ten.