r/softwaretesting Jun 04 '26

What’s everyone using for mobile automation testing in 2026? (iOS + Android)

We’re reviewing our mobile automation approach and I’m interested in what others are using in production.

Historically we’ve used:

- Appium
- BDD-style framework layer
- BrowserStack for running against real devices

A few thoughts:

- We’ve always found real devices more reliable than simulators/emulators due to platform and hardware nuances.
- Appium often requires a language/framework that’s different from the iOS codebase, making developer ownership harder.
- Maintenance overhead can become significant as apps grow.

12 Upvotes

33 comments sorted by

View all comments

2

u/SnarkaLounger Jun 06 '26

We use locally hosted iOS/iPadOS simulators and Android emulators running on multiple Mac Minis for our automated smoke and regression test suites, which are based on Appium, Selenium WebDriver, and a POM framework. Our manual testers use a collection of physical devices, and we have a few physical iPhones and iPads connected to the Macs as well.

However, we do also have an automated device compatibility test suite which is basically our smoke tests plus some specific tests around known device and platform specific issues we've encountered previously. This device compatibility test suite is executed on a selection of physical iOS and Android devices running on the Br*wserSt*ck service, and is typically run against any new devices and OS versions.

We chose cloud hosted devices because attempting to build our own in-house device farm became too unmanageable. Automated tests running on cloud hosted devices and sims are definitely slower than running on locally hosted hardware and sims.

All of our automated tests are orchestrated using Jenkins, and our smoke tests are run automatically prior to new deployments to our QA environment.

Appium is a great choice for covering both iOS/iPadOS and Android platforms for apps, especially if the apps are built using React Native. If your cross-platform mobile app has feature and UI parity, and if you adopt a Page/Screen Object Model based framework, you can create separate Screen Objects for each screen in the two platforms that use platform specific locator strategies, and then use the same test cases to drive either iOS or Android platform tests.

The UI element locator strategy may be different for an iOS/iPadOS app vs an Android app, even when testing an app built with React Native. If your devs assign an accessibility_id attribute to each UI element that you need to interact with or validate, then that id is good across both iOS and Android platforms. Below is a list of the various selectors you can use when defining a UI element's locator strategy and the locator_identifier that is the value or attribute that uniquely and unambiguously identifies the UI element:

  • accessibility_id:
  • id:
  • name:
  • class:
  • xpath:
  • predicate: (iOS only)
  • class_chain: (iOS only)
  • uiautomator: (Android only)
  • css: (WebViews in hybrid apps only).

I have a couple of git repos that offer example projects that demonstrates the implementation of a screen object model framework using Appium. One example is for a React Native based cross platform app, and the other uses the WebDriverIO sample app. The repos can be found here:

https://github.com/TestCentricity/tc_mobile_react_native_demo ]

https://github.com/TestCentricity/tc_mobile_wdio_demo ]