Design and Implementation of an iOS Remote Real‑Time Testing Platform

Autohome's mobile business has grown rapidly, leading to a larger R&D team and increasing demand for testing devices and resources; testing across many device models has become difficult, prompting the need for an efficient way to utilize mobile test devices.

The current approaches—internal purchase of popular models, inter‑department borrowing, ignoring unpopular models, and renting cloud devices—each suffer from cost, testing cycle, efficiency, or user‑experience drawbacks.

After researching industry solutions, the team noted that Android benefits from mature open‑source cloud‑device platforms such as OpenSTF, while iOS lacks comparable open‑source options, with only costly commercial cloud services available. Consequently, they decided to develop their own iOS real‑time testing platform.

The platform must provide real‑time screen streaming with high frame rate, low‑latency remote control, and capabilities for app installation and system log retrieval.

For screen transmission, three methods were considered: using libimobiledevice's screenshot tools ( ideviceinfo , idevicesyslog , idevicescreenshot , ideviceinstaller ) which only achieve 2‑5 fps; QuickTime‑Player leveraging AVFoundation and CoreMediaIO (not integrable); and iOS‑minicap, an OpenSTF project that uses AVFoundation/CoreMediaIO and turbojpeg to deliver up to 20 fps. The iOS‑minicap solution was chosen.

To forward user interactions (tap, swipe, text input) to the device, several automation drivers were evaluated: Apple’s XCTest/XCUITest, Facebook’s WebDriverAgent (WDA), Appium, and Alibaba’s Macaca XCTestWD. The team selected WDA as the event‑driving component.

For data forwarding between the Mac host and the iOS device, two options existed: the now‑unmaintained peertalk library and libimobiledevice’s iproxy . Because iproxy is easier to deploy on the Mac side, it was adopted.

App installation and log collection rely on libimobiledevice tools ( ideviceinstaller for app install and idevicesyslog for logs).

The overall system follows a B/S architecture: a web front‑end (browser) displays device status and initiates connections; a Django backend handles authentication, queries Redis for device information, and forwards connection requests to a unified scheduling platform; the scheduling platform coordinates Mac agents that manage iOS devices and communicate with the front‑end via WebSocket; each Mac runs an iOS device scheduler that uploads device metadata to Redis and handles RPC calls.

Several optimizations were implemented: the tap method was rewritten using the private API XCEventGenerator to achieve millisecond‑level response and privileged operations; the drag method was also reimplemented with XCEventGenerator to keep latency under 200 ms; a 40 ms timer was added to iOS‑minicap to cap the frame rate at 25 fps, stabilizing output at 20‑25 fps; WDA startup was delayed until iOS‑minicap had sent its first frame, avoiding resource conflicts with xcodebuild ; additional features such as log streaming, character input, and screen clearing were added.

These improvements resulted in a stable 20+ FPS video stream, millisecond‑level tap response, and sub‑200 ms swipe latency, as demonstrated in the accompanying screenshots.

Future work includes enhancing log visualization, implementing remote IDE debugging (in progress), adding iOS visual automation, device clustering, multi‑screen operation, and exposing service APIs.

The team invites interested colleagues to discuss, contribute, and collaborate on the project.