Overcoming iOS Automation Testing Challenges with Private APIs, xcodebuild, and Curl‑Driven WebDriverAgent

Last year the author wrote an article titled "Opportunities for Testing in the Containerization Era" that explored combining distributed automation testing with container technologies. The current piece shifts focus to the specific challenges of iOS automation testing for complex business scenarios.

Mobile applications are usually designed for simplicity and short user flows, so typical iOS app testing is straightforward and only requires a compatible macOS version and Xcode environment.

However, large‑scale enterprise mobile apps—such as e‑commerce platforms or ride‑sharing services—introduce three major problems:

1. Massive test suites cause excessively long feedback times. The author notes that mainstream iOS automation frameworks like Appium and Calabash are widely used, but after Xcode 7 the iOS Simulator became slower, and Apple dropped UIAutomation after iOS 10/Xcode 8, removing many useful APIs. Appium still lacks an official library for iOS 10, making element location with the inspector difficult, and the Instrument singleton limitation (only one Instrument session per physical host) further hampers parallel testing.

2. Complex scenarios cannot be executed on a single machine. Real‑world use cases often require multiple simulators running different user roles (e.g., passenger and driver in a ride‑sharing app). Controlling several simulators simultaneously on one host incurs high hardware costs and performance penalties, and existing frameworks struggle to manage such concurrent interactions.

3. Test flows need to switch between different apps. Many features involve interactions with system apps, notifications, or network‑state changes, requiring the test to jump from the target app to other applications and back.

To address these issues, the author proposes three solutions:

Problem 1 – Solving the Instrument singleton limitation. By leveraging Apple’s private APIs, it is possible to batch‑operate multiple simulators—starting, resetting, installing, and running apps—thereby bypassing the one‑instrument restriction.

Problem 2 – Controlling different simulators in complex scenarios. The xcodebuild command can launch WebDriverAgent on a chosen device, but Apple’s tooling normally shuts down other sessions. The workaround is to start separate processes on different ports for each device. A sample curl request demonstrates how to obtain a session for a specific app:

curl -X POST -H "Content-Type: application/json" -d "{\"desiredCapabilities\":{\"bundleId\":\"com.apple.Preferences\"}}" http://localhost:8101/session

The response returns a JSON object containing the session ID and device capabilities, which can be used for further actions.

Additionally, an HTTP server can host an inspector to locate elements even in system apps.

Problem 3 – Switching between different apps during a test. Using the same curl approach, different apps can be launched and their session IDs retrieved, enabling seamless app switching without relying on Appium’s APIs.

These techniques raise the question of whether to abandon Appium altogether. By adopting Uber’s Octopus framework together with WebDriverAgent, teams can issue HTTP requests to perform actions such as query, tap, type, and Touch ID directly on the device. This eliminates the need for Appium’s API layer, improves execution speed, and offers greater flexibility for concurrent and complex business scenarios.

The author notes that while the approach reduces scripting effort and language dependence, the overall cost may still outweigh the benefits for many teams due to high maintenance and rapid UI changes. A demo using ThoughtWorks’ StartKit illustrates a simple login‑page test implemented with this method.

In conclusion, the author encourages practitioners to step back from routine constraints, simplify complex problems, and continuously explore new ways to make testing more efficient.