iPhone-use、Appium 与 iPhone Mirroring：真实 iPhone 怎么选？
资料核验：2026-10-29
让 AI 操作手机、维护自动化测试，以及自己在 Mac 上使用 iPhone，是三种不同的需求。
如果你希望 Codex 或 Claude Code 根据当前画面操作真实 iPhone，并且设备符合当前已验证环境，可以从 iPhone-use 的 standard 模式开始。如果你要维护 iOS / Android 自动化测试或沿用现有 WebDriver 流程，优先评估 Appium。如果只是自己用 Mac 的鼠标和键盘操作手机，先看 Apple 的 iPhone Mirroring。
下面比较接入方式、环境要求与使用边界。本文由 iPhone-use 项目提供，依据项目文档与各方官方资料整理；没有进行三者的同条件性能测试。
三条路线的主要区别
| 选择依据 | iPhone-use | Appium（iOS 使用 XCUITest Driver） | Apple iPhone Mirroring |
|---|---|---|---|
| 值得优先考虑的场景 | 已有本地 AI Agent，需要设备观察与操作工具 | 维护测试脚本，复用 WebDriver 客户端及多平台驱动 | 人在 Mac 上直接操作附近的 iPhone |
| 接入方式 | Agent 调用 Mac CLI；提供 Codex / Claude Code 插件 | 客户端调用 Appium 服务，再由对应驱动控制设备 | 在 Mac 上打开镜像窗口，用鼠标、触控板和键盘操作 |
| 界面信息 | standard 提供截图；runner 另提供可用辅助功能元素 | 截图与元素定位能力，可按元素属性或层级查询 | 可交互的镜像画面；Agent 接入需另行验证桌面控制方案 |
| 真机辅助程序与签名 | standard 无需 Runner；runner 需要签名并安装项目自己的 XCTest Runner | WDA 需要有效签名与描述文件；可以复用已准备好的 WDA | Apple 的常规使用流程不要求配置测试 Runner |
| 观看过程 | 内置只读本地浏览器预览 | WDA 的 MJPEG 画面流可用于实时观看 | 直接观看并操作镜像窗口 |
表中 Appium 的平台架构、元素能力、签名与画面流分别见 Appium 简介、元素定位、真机签名和 MJPEG 画面流。Apple 的使用方式见 iPhone Mirroring 官方说明；iPhone-use 的模式与预览见设备准备和本地预览。
用 Codex 或 Claude Code 操作现有 App：先看 iPhone-use
iPhone-use 是开源 macOS CLI：它提供截图和设备动作，Agent 负责理解任务、选择下一步并核对结果。客户端需要能在连接手机的 Mac 上执行命令、读取实际 PNG 图片。项目提供的插件直接调用 CLI，无需另外启动 MCP 服务。
两种模式适合不同的观察方式：
- standard：根据截图选择坐标，通过原生 HID 操作，省去 Runner 安装与开发签名。
- runner：通过 XCTest 操作，并提供可用的辅助功能元素，适合需要元素引用的流程；需要为项目自己的 Runner 准备开发签名。
两种模式都需要完整 Xcode、设备信任、开发者模式和解锁。standard 当前要求 macOS / iOS 27。0.5.0 正式包的公开验收环境是 Apple Silicon、macOS 27.0、Xcode 27.1、iPhone 12 Pro / iOS 27.0.1；Runner 使用已有付费开发签名。其他设备组合、全新 Mac 和免费 Personal Team 首次配置与续签尚未验收，不能从二进制最低安装版本推导出这些环境已受支持。0.5.0 发布与验收记录
因此，iPhone-use 的选型价值在于已有的 Agent 接入流程，以及 standard 模式省去 Runner 准备这一步。如果你的环境不在已验证范围，或项目必须覆盖 Android、模拟器和大量既有测试用例，就应先评估其他路线。具体安装步骤见客户端指南。
维护自动化测试：优先评估 Appium
Appium 将核心服务、平台驱动与不同语言的客户端分开。对于已有测试脚本、需要覆盖多平台的团队，这种结构有利于沿用现有测试组织方式；iOS 和 Android 仍需各自的驱动与平台配置，不能据此假定一份脚本无修改地通用。Appium 架构说明
Appium 也能面向已安装 App：XCUITest Driver 支持通过 bundle ID 指定应用，并不局限于从源码构建自己的 App。因此，“操作现有 App”本身不足以决定选哪种工具。进一步的选择依据是：是否已有 Agent 接入方式，是否需要沿用定位器、测试步骤和断言，以及愿意维护哪些组件。Appium 也可以作为 Agent 调用的执行工具，但接入哪种客户端、如何传递截图和处理失败，需要在所选集成中确认。应用配置
环境准备也要按具体驱动看。XCUITest Driver 的常规路线使用 macOS、Xcode 和 Appium，并通过 WebDriverAgent（WDA）连接设备。旧 iOS 可能需要配套的旧 Xcode、驱动和 Appium 版本，应按官方兼容表选组合，不能笼统承诺兼容所有旧系统。系统要求
官方也记录了受限的 Windows / Linux 主机方案：需要 iOS / tvOS 18 或更新的真机、RemoteXPC 配置，以及预装或外部管理的 WDA；这些主机不能按常规 Xcode 路线构建 WDA。如果没有 Mac，可以评估这条路线，但须先确认 WDA 的准备与管理条件。非 macOS 主机指南
自己在 Mac 上操作手机：先看 iPhone Mirroring
Apple 的 iPhone Mirroring 适合直接在 Mac 窗口里使用 iPhone App。它要求 Apple Silicon 或 T2 Mac、macOS 15 或更新版本、iOS 18 或更新版本；两台设备使用同一个开启双重认证的 Apple Account，开启 Wi-Fi 与蓝牙，iPhone 在附近并保持锁定。核验时 Apple 仍注明欧盟不可用。Apple 官方要求
如果这是你全部的需求，可以先使用镜像功能。若要让 AI 操作这个窗口，则还需选择并验证桌面控制工具；镜像连接成功只能证明人可以通过窗口操作，不能替代 Agent 的读图、输入与结果验证。
还要区分“看见”和“控制”：iPhone-use 的浏览器预览用于观看，不能在网页上点击手机；iPhone Mirroring 的窗口可以交互；Appium 的 WDA 也提供供浏览器或其他客户端观看的 MJPEG 流。是否能看过程，不足以单独决定使用哪种控制工具。iPhone-use 预览说明、Appium 画面流说明
想省掉签名，或寻找“更轻量”的 Appium 替代方案？
先明确希望减少哪部分准备工作。
直接调用 WDA 可以省去 Appium 服务这一层，但只要仍在真机上使用 WDA，就仍需满足 WDA 的签名与描述文件要求。复用预编译、预安装的 WDA 可以改变准备方式，不等于 WDA 无需签名。WDA 签名要求
iPhone-use standard 使用不同的控制路线，省去了 Runner 与 WDA；代价是当前环境要求较窄，且观察不提供元素引用。选择 iPhone-use runner 后，开发签名仍然需要，只是使用项目自己的 XCTest Runner。模式比较
因此，更有用的比较是“少安装或维护了哪些组件、失去了哪些能力、环境是否适用”。组件数量不能代替任务耗时与成功率的测试。
选定路线后，用自己的任务验证
先选一个你实际需要的短流程，例如打开现有 App、进入指定页面，再读取结果。验收时分别确认：
- 环境与连接可用；使用 Agent 时，确认它能实际读取截图。
- 输入后到达预期页面或状态，而不仅是命令返回成功。
- 需要观看时能打开画面；任务结束后能正常释放连接。
若要比较速度与可靠性，再固定设备、App 状态、任务、工具版本，以及使用 AI 时的模型和提示词，记录首次配置时间、重复任务耗时、成功次数和失败原因。本文没有这类横向实测数据，因此不据此宣称某条路线更快或成功率更高。