# appium Published articles for appium. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Maestro vs Appium: The Benchmark DevFeed: [Maestro vs Appium: The Benchmark]() Original publisher: [Read original article]() Author: Manu Armani Published: 2026-08-17T10:00:00Z Content type: comparison Language: en Sources: [mobile.dev - Medium]() Topics: [Benchmark](), [Mobile](), [cross-platform](), [AI Agent](), [Command-line interface](), [YAML](), [Selenium]() Tags: [agent](), [ai](), [ai-coding](), [android](), [appium](), [benchmark](), [claude](), [claude-code](), [cli](), [cost](), [cross-platform](), [ios](), [javascript](), [maestro](), [maintenance](), [mcp](), [python](), [selenium](), [vs]() ### AI overview A comparison of Maestro and Appium for mobile UI testing across setup, syntax, waits, flakiness, platform coverage, AI agent support, and maintenance cost. Maestro uses declarative YAML flows with built-in waits and retries, while Appium uses code-based tests and a driver architecture covering more platforms. The article also describes MCP-based device control and cases where Appium is the better fit. ### Source excerpt A side-by-side comparison of Maestro and Appium across setup, syntax, waits, flakiness, cross-platform coverage, AI agent support, and maintenance cost. ## How a Learning Project Became Our Modern Mobile Test Framework DevFeed: [How a Learning Project Became Our Modern Mobile Test Framework]() Original publisher: [Read original article]() Author: Raymond Saba I'm an SDET who enjoys building test automation; Finding Ways Published: 2026-02-18T00:00:00Z Content type: article Language: en Sources: [Trivago]() Topics: [Mobile](), [Automation](), [webDriver](), [Concurrency](), [Java]() Tags: [appium](), [automation](), [engineering](), [java](), [migration](), [mobile](), [modularity](), [overhead](), [quality-assurance](), [standards](), [threads](), [webdriver]() ### AI overview This engineering article describes how trivago's aging homegrown mobile automation framework evolved into a shared iOS and Android test framework. It covers the transition from Appium 1 to Appium 2 and later Appium 3, including a rewrite based on W3C WebDriver standards, platform-specific drivers, modularity, and parallel execution with threads in one JVM. ### Source excerpt About six years ago, our mobile automation setup was showing its age. It was a small, homegrown framework that had worked "well enough" for a long time, until we tried to upgrade Java and a few ... ## Wahed Accelerates React Native Mobile Testing with Maestro DevFeed: [Wahed Accelerates React Native Mobile Testing with Maestro]() Original publisher: [Read original article]() Author: Jake Krupski Published: 2025-05-28T10:24:00Z Content type: article Language: en Sources: [mobile.dev - Medium]() Topics: [Mobile Testing](), [Test automation](), [React Native](), [Testing](), [Open Source]() Tags: [appium](), [case-study](), [fintech](), [maestro](), [mobile-test-automation](), [mobile-testing](), [react-native]() ### AI overview This case study describes how Wahed adopted Maestro for automated testing of its React Native mobile app. Test writing time fell from 3-4 hours per test with Appium to 10-15 minutes, releases shifted from biweekly to weekly, and automated test coverage grew from 50 manual smoke tests to approximately 250 tests. ### Source excerpt The world of mobile app development is fast-paced, demanding rapid iterations and flawless user experiences. But what happens when your mobile app testing process cannot keep up... ## Case Study: How Eneco Upgraded from Manual QA to Automated Testing with Maestro DevFeed: [Case Study: How Eneco Upgraded from Manual QA to Automated Testing with Maestro]() Original publisher: [Read original article]() Author: Jake Krupski Published: 2025-04-09T00:00:00Z Content type: article Language: en Sources: [mobile.dev - Medium]() Topics: [Testing](), [Automation](), [Mobile](), [Selenium]() Tags: [appium](), [automated](), [automation](), [automation-tools](), [case-study](), [maestro](), [mobile](), [open-source](), [qa](), [selenium](), [testing]() ### AI overview A case study of Eneco's transition from manual QA to automated testing across its mobile app and web portal. The team evaluated Appium, Tosca, and Maestro, with Maestro selected for its reported speed, reliability, simpler learning curve, and integration fit. The article also describes internal adoption after demonstrations to QA teams and company leadership. ### Source excerpt At Mobile.dev, we love hearing stories from teams putting Maestro to work in the real world - and Randy Sie and his team at Eneco have a story that's representative of what many... ## Introducing native E2E testing: Learnings from the Senior Engineering Program for Women DevFeed: [Introducing native E2E testing: Learnings from the Senior Engineering Program for Women]() Original publisher: [Read original article]() Author: Joana Melo Published: 2023-09-08T12:35:44Z Content type: article Language: en Sources: [Klarna Engineering]() Topics: [Testing](), [App](), [Development]() Tags: [appium](), [automated](), [diversity](), [e2e-testing](), [engineering](), [gender](), [gender-equality](), [klarna](), [learnings](), [professional-development](), [regression](), [testing](), [typescript]() ### AI overview The author describes introducing native end-to-end testing in mini versions of the Klarna app to enable automated feature regression tests in development pipelines. The article also reflects on the Senior Engineering Program for Women, including its focus on professional growth, coaching, collaboration, technology, influence, and diversity. ### Source excerpt I made company-wide impact by successfully delivering the introduction of native end-to-end (E2E) testing in mini versions of the Klarna app. The goal was to have automated feature regression tests in our pipelines. I developed this as part of a program for senior engineering women, and today, I want to share the insights and learnings I gained from this experience. Creating fair and equal opportunities for women How do we offer women equal and fair opportunities in an industry dominated by men? Well, there are many ways to work on this topic. One that piqued my curiosity was Klarna's Senior Engineering Program for Women (SEPW). As you might wonder as well, my initial thoughts on it as with any other initiatives like this came with a lot of reservations: Is this fair? Is this the best way for me to ensure that I'm being fairly evaluated? Will it look like I am being brought to a speedlane towards an easy promotion if I happen to get one because I'm a woman? Are we going to get treated like tokens? Is this all just a marketing strategy to promote? Am I being part of and legitimizing something that has no real content and value for my career or other women? What will everyone think? When we are faced to join initiatives related to gender gap improvements, we might fall into the trap of having all the perfect and right answers before we take risks, or we can accept that there will never be the perfectly carved, impactful and life-changing solution at our doorstep. We can only experiment and learn from the results to make better decisions as we help evolving into a hopefully more gender-fair world. As a woman in engineering, I understand the issues, but I don't claim to have all the answers. And that's ok. The program The SEPW is a way for Klarna to acknowledge and accelerate the professional development of promising engineers and promote diversity within engineering. The 6 month program is designed with the individual's growth as the main focus, and based on four theme ## How Hydra Lab Empowers Microsoft Mobile Testing DevFeed: [How Hydra Lab Empowers Microsoft Mobile Testing]() Original publisher: [Read original article]() Author: TechHome Published: 2023-07-26T04:12:12Z Content type: article Language: en Sources: [Android@Microsoft - Medium]() Topics: [Mobile Testing](), [Testing](), [API](), [DevOps](), [Azure DevOps](), [Microsoft](), [Open Source]() Tags: [ai](), [android](), [api](), [appium](), [automation](), [azure](), [chatgpt](), [ci](), [devops](), [github](), [hydra](), [integration](), [ios](), [maestro](), [microsoft](), [mobile](), [mobile-testing](), [open-source](), [testgpt](), [testing]() ### AI overview The article describes Hydra Lab, an open-source framework for building a private, self-managed mobile test cloud with a REST API and DevOps integration. It explains the framework's focus on control, customization, cost, device sharing, test automation, and test intelligence, and describes its use in Microsoft mobile-product testing through Azure DevOps pipelines. ### Source excerpt How Hydra Lab Empowers Microsoft Mobile Testing and Test Intelligence Hydra Lab: Intelligent Cloud Testing Made Easy -- microsoft/HydraLab (github.com) What is Hydra Lab? The following video could give you an overview of Hydra Lab on its functionality status and mission. https://medium.com/media/34f0f3cb9ff8eafe8b4c2c90e5d5fa30/href In other words, with Hydra Lab, you can build a private test cloud on your own which provides RESTful API service and support for DevOps system integration. In other words, it's like you can have a private self-manageable "Firebase Test Lab". Why we need Hydra Lab We open-sourced Hydra Lab under github.com/microsoft in 2022 Dec, and its open-source nature ensures better control and customization, removing the following concerns when it comes to the integration of cloud testing platform: [Credibility]: Is it okay to upload your debug app package to a 3rd party platform? Could we trust them? Is there a compliance requirement for using it? [Customization]: Does the 3rd party platform have the compatible real devices to run my test? Is cross-platform scenario supported? [Cost]: Is the pricing of those platforms affordable? [Community]: Could we plug in our devices to the cloud and share them across geos & teams? Hydra Lab is a free, customizable, credible framework built on top of Appium, Espresso, Maestro, XCTest, etc. It has been geared with test integration glue code and scalable designs and test lifecycle definition for further support of new runners and test intelligence. The Hydra Lab team put consistent effort in contributing to the mission of "Intelligent Cloud Testing Made Easy" and designing "Your Intelligent Test Cloud", we have built standardized CI and CD procedures in Azure DevOps with UT and API+E2E acceptance testing as quality gatekeepers and have shipped 27 stable releases so far. How Hydra Lab powers testing in Microsoft After integrating Hydra Lab into our procedures over the past two years, our in-house service now stream ## Maestro -- Re-Building the iOS Driver DevFeed: [Maestro -- Re-Building the iOS Driver]() Original publisher: [Read original article]() Author: Amanjeet Singh Published: 2022-12-27T08:00:00Z Content type: release Language: en Sources: [mobile.dev - Medium]() Topics: [iOS](), [Accessibility](), [User interface design](), [Command-line interface](), [Vanilla JavaScript]() Tags: [accessibility](), [appium](), [cli](), [ios](), [maestro](), [swiftui](), [ui]() ### AI overview Maestro 1.18 introduces a rebuilt iOS driver that provides a more complete understanding of UI layout and improves discovery of previously missing or hard-to-find elements. The article explains Maestro's view-matching approach and describes its OS-agnostic device interface and initial use of Facebook's IDB tool. ### Source excerpt If you were using Maestro for iOS in the past, chances are -- you have seen the issues with elements not being easily discoverable or outright missing. No more! ## UI tests with Jetpack Compose and Appium x UIAutomator DevFeed: [UI tests with Jetpack Compose and Appium x UIAutomator]() Original publisher: [Read original article]() Author: Julien Salvi Published: 2022-12-05T13:01:16Z Content type: tutorial Language: en Sources: [Stories by Julien Salvi on Medium]() Topics: [ui-testing](), [Jetpack Compose](), [Android](), [Testing](), [Instrumentation]() Tags: [android](), [appium](), [compose](), [instrumentation](), [jetpack-compose](), [testing](), [tests](), [ui-testing](), [uiautomator]() ### AI overview This tutorial explains how Aircall adapted Android UI automation tests when migrating from View-based components to Jetpack Compose. It describes using Compose semantics and testTag values mapped to resource IDs, then locating the resulting components with UiSelector in Appium and UIAutomator. ### Source excerpt At Aircall we are pushing a lot around quality thanks to our great QA team. Huge efforts are put on Android developer side with the unit tests and our QA engineers tackle everything around automation & UI tests. Before integrating our brand new design system made with Compose UI in production, we wanted to be sure that the transition to Compose would be painless with our automation framework and tools: Appium and UIAutomator. This article will explain how the Android team validated the move to Compose with our automation framework. Automation tests with View components The Aircall QA team has developed lots of automation tests that cover more than 90% of the use cases in the Android app. And to do so, they rely on Appium with the UI testing framework UIAutomator which is an instrumentation-based API and works with the AndroidJUnitRunner test runner. To locate a View-based component in the application, UIAutomator provides an annotation @AndroidFindBy where you need to specify the resource id of a UI element you want to identify. @AndroidFindBy(id = "myButtonId") protected WebElement myButton; But this method does work properly with Compose UI components. Indeed, when looking for a Composable with its dedicated tag, no elements are found in the screen. Now, let's have a closer look at the changes we had to make in order to smoothly add our new Compose code in the current codebase and not breaking everything on the automation side. UI tests with Compose UI and UIAutomator To unlock the UI testing with UIAutomator and Compose, we will have to take advantage of the semantics Modifier in each Composable we want to locate with the testTag property. In order to ease the migration, we are going to keep the same component IDs we were using with our View-based elements. Modifier.semantics { testTag = "myButtonId" } And at the top level Composable, we should toggle the configuration to map testTags to the resource IDs in the semantics Modifier. This will allow the automation f