iPhone-use, Appium or iPhone Mirroring: which should you choose?
Sources checked: October 29, 2026
Having AI operate a phone, maintaining automated tests and using your iPhone yourself from a Mac are different needs.
If you want Codex or Claude Code to operate a real iPhone from its current screen, and your devices match the tested environment, start by evaluating iPhone-use standard mode. If you maintain iOS / Android tests or an existing WebDriver workflow, evaluate Appium first. If you simply want to use your Mac’s mouse and keyboard to operate your phone, start with Apple’s iPhone Mirroring.
This guide compares integration, requirements and limits. It is provided by the iPhone-use project and draws on project documentation and official sources. We have not benchmarked the three approaches under identical conditions.
The main differences
| Decision | iPhone-use | Appium (XCUITest Driver for iOS) | Apple iPhone Mirroring |
|---|---|---|---|
| When to consider it first | An existing local AI agent needs device observations and actions | Maintaining test scripts and reusing WebDriver clients and platform drivers | A person operating a nearby iPhone from a Mac |
| Integration | The agent calls a Mac CLI; Codex / Claude Code plugins are available | A client calls the Appium server, which uses the appropriate device driver | Open the Mac mirroring window and use the mouse, trackpad and keyboard |
| Screen information | Screenshots in standard; runner also provides available accessibility elements | Screenshots and element lookup by attributes or hierarchy | An interactive mirrored screen; agent integration requires separately validating a desktop-control tool |
| Device helper and signing | No Runner in standard; runner requires the project’s signed XCTest Runner | WDA needs valid signing and provisioning; an already prepared WDA can be reused | Apple’s normal setup does not require a test Runner |
| Watching the task | Built-in, read-only local browser preview | WDA’s MJPEG stream supports live viewing | Watch and interact directly in the mirroring window |
For Appium’s architecture, elements, signing and streaming, see the Appium introduction, locator strategies, real-device provisioning and MJPEG stream guide. See Apple’s iPhone Mirroring guide for its workflow, and iPhone-use’s device setup and local preview for its modes and viewer.
Operating existing apps with Codex or Claude Code: consider iPhone-use
iPhone-use is an open-source macOS CLI. It provides screenshots and device actions; your agent interprets the task, chooses actions and verifies results. The client must execute commands on the Mac connected to the phone and read actual PNG images. The project’s plugins call the CLI directly, without a separate MCP server.
The two modes provide different ways to observe the screen:
- standard: choose coordinates from screenshots and act through native HID, without Runner installation or development signing.
- runner: act through XCTest and use available accessibility elements for workflows that need element references. This requires development signing for the project’s own Runner.
Both modes need full Xcode, device trust, Developer Mode and an unlocked phone. Standard currently requires macOS / iOS 27. The published acceptance environment for the 0.5.0 package is Apple Silicon, macOS 27.0, Xcode 27.1 and iPhone 12 Pro / iOS 27.0.1; Runner was tested with existing paid development signing. Other device combinations, a fresh Mac and initial free Personal Team provisioning or renewal have not been validated. The binary’s minimum installation version does not establish support for those environments. See the 0.5.0 release and acceptance record.
The reasons to evaluate iPhone-use are its existing agent integration and the Runner preparation step that standard mode removes. If your environment falls outside the tested scope, or your project must cover Android, simulators and substantial existing test suites, evaluate other approaches first. Installation steps are in the client guide.
Maintaining automated tests: evaluate Appium first
Appium separates its core server, platform drivers and language-specific clients. For teams with existing scripts and multiple platforms, this structure can help preserve their test workflow. iOS and Android still need their own drivers and platform configuration; this does not mean that one script works unchanged on both. See Appium’s architecture.
Appium can also target installed apps: XCUITest Driver accepts an app’s bundle ID, so its use is not restricted to building your own app from source. Operating an existing app alone does not decide the choice. Consider whether you already have an agent integration, need to retain locators, test steps and assertions, and which components you are willing to maintain. Appium can serve as an agent’s execution tool too, but client integration, screenshot delivery and failure handling need to be checked in the integration you choose. See app configuration.
Requirements depend on the driver. The usual XCUITest Driver setup uses macOS, Xcode and Appium, and connects to the device through WebDriverAgent (WDA). Older iOS versions may require matching older versions of Xcode, the driver and Appium. Use the official compatibility tables rather than assuming all older systems are supported. See system requirements.
The official documentation also describes limited Windows / Linux host support. It requires real devices on iOS / tvOS 18 or later, RemoteXPC configuration and preinstalled or externally managed WDA. These hosts cannot build WDA through the usual Xcode workflow. If you do not have a Mac, evaluate this path only after checking how WDA will be prepared and managed. See the non-macOS host guide.
Operating the phone yourself from a Mac: consider iPhone Mirroring
Apple’s iPhone Mirroring lets you use iPhone apps directly in a Mac window. It requires an Apple Silicon or T2 Mac with macOS 15 or later, and an iPhone with iOS 18 or later. Both devices must use the same Apple Account with two-factor authentication, with Wi-Fi and Bluetooth enabled; the iPhone must be nearby and locked. At the time of this review, Apple still lists it as unavailable in the European Union. See Apple’s requirements.
If that meets your entire need, try mirroring first. To have AI operate that window, you still need to choose and validate a desktop-control tool. A successful mirroring connection establishes that a person can operate the window; it does not validate an agent’s image reading, input or result checking.
Viewing and control also differ: iPhone-use’s browser preview is for watching and does not accept phone clicks; iPhone Mirroring is interactive; Appium’s WDA also offers an MJPEG stream for browsers and other clients. Being able to watch a task is not enough on its own to choose a control tool. See the iPhone-use preview guide and Appium streaming guide.
Avoiding signing or looking for a lighter Appium alternative?
First identify which setup work you want to remove.
Calling WDA directly can remove the Appium server layer, but WDA on a real device still needs valid signing and provisioning. Reusing a prebuilt or preinstalled WDA changes the preparation workflow; it does not make WDA unsigned. See WDA signing requirements.
iPhone-use standard uses a different control path, without Runner or WDA. Its trade-offs are a currently narrow environment requirement and observations without element references. Choosing iPhone-use runner still requires development signing, using the project’s own XCTest Runner. See the mode comparison.
Compare which components you no longer need to install or maintain, which capabilities you give up and whether your environment fits. Component count cannot substitute for measurements of task duration and success rate.
Validate the approach with your own task
Choose a short workflow you actually need, such as opening an installed app, navigating to a particular page and reading the result. Verify separately that:
- The environment and connection work; when using an agent, confirm that it actually reads the screenshot.
- The input reaches the intended page or state, rather than merely returning a successful command receipt.
- You can open a viewer when needed and release the connection after the task.
To compare speed and reliability, fix the device, app state, task and tool versions, plus the model and prompt when using AI. Record initial setup time, repeated task duration, successes and failure causes. This guide has no such comparative measurements, so it does not claim that one approach is faster or more reliable.