USB or Wi-Fi for iPhone automation: why Mobster uses the cable

Every tool that drives an iPhone from a computer answers two questions: how it reads the screen, and how its taps reach the phone. The second answer decides who else could tap Send on your phone. Mobster’s answer is the USB cable, on purpose: the runner that controls your iPhone answers the cable and nothing else.

How Mobster reaches the phone

Mobster drives an iPhone through WebDriverAgent, an XCTest runner maintained by the Appium project. Xcode builds it, signs it with your Apple Account and installs it on the phone. Once it runs, it serves the phone’s accessibility tree and accepts taps and typing over HTTP on port 8100, and streams the screen as MJPEG on port 9100.

Those ports live on the phone. To reach them from the Mac, Mobster runs iproxy from libimobiledevice, which relays a port on the Mac to a port on the phone through usbmux, the channel the USB cable carries:

$ iproxy -s 127.0.0.1 -u <UDID> 8100:8100 9100:9100

Three servers are involved, and none of them answers another machine:

The runner has no password, so Mobster locks it to the cable

WebDriverAgent has no authentication of its own. Anything that can reach its port can read the screen and tap, type and swipe as you. Out of the box, the runner listens on every interface of the phone, its Wi-Fi address included, and an iproxy started without a bind address listens on every interface of the Mac: lsof shows it on *:8100. On a shared network, that’s an open door to your phone.

Mobster closes it in three places:

1. The runner listens on the phone’s loopback. Mobster builds WebDriverAgent with USE_IP=127.0.0.1, so it binds the address usbmux reaches over USB, not the phone’s Wi-Fi address.
2. The video stream follows, and both refuse strangers. Upstream, the MJPEG socket listens on every interface no matter what. Mobster patches the pinned WebDriverAgent source so the stream binds the same address as the API, and so both refuse a request from a browser or one that names a host other than this Mac. If the patches don’t fit the source, the build fails instead of running open.
3. The relay listens on 127.0.0.1 only. Mobster runs iproxy with -s 127.0.0.1 and refuses an iproxy too old to take that flag, with the fix:

This iproxy can't be limited to this Mac. Update it: brew upgrade libimobiledevice libusbmuxd

Simulators get the same treatment: WebDriverAgent listens on 127.0.0.1, and Mobster checks both ports with lsof after starting it and stops the runner if either one listens beyond the Mac. Mobster treats reaching the runner or the local API from another machine as a security vulnerability.

The bar for going wireless

To drive a phone over Wi-Fi, the runner has to be reachable from your Mac across the network, and from nothing else on it: not the coffee shop’s Wi-Fi, not the office’s, not a guest on yours. That takes either a secret checked on every request, which upstream WebDriverAgent doesn’t do, or a tunnel that only your Mac can open. Either one is code that decides who can tap Send on your phone. Until a wireless path clears that bar on a real phone, Mobster keeps your iPhone on the cable.

How other tools reach the phone

From each project’s site, docs and README:

• TapKit captures the screen over USB and taps over Bluetooth, with AssistiveTouch on. Its MCP server and API send your agent’s commands through TapKit’s servers, and screenshots come back the same way and TapKit stores them (its security page, read 8 October 2026).
• Bluetooth open-source apps such as Taplyne and xhoantran’s iphone-use act through AssistiveTouch too, from screenshots (read 8 October 2026).
• iPhone Mirroring tools such as phone-harness and mirroir-mcp drive the Mirroring window on the Mac. Apple’s iPhone Mirroring works with one iPhone at a time, needs the phone nearby and locked and one Apple Account on both devices, and isn’t available in the EU.

Mobster’s trade is setup, Developer Mode and Xcode, for the accessibility tree, simulators, and a runner that answers only the cable, with no cloud in between. How Mobster compares puts them side by side, and Mobster vs TapKit goes row by row.

Living with the cable

• Use a data cable. Some cables only charge. With the phone plugged in and unlocked, idevice_id -l prints its UDID.
• Trust this Mac. The first time, the phone asks whether to trust the computer. Tap Trust and enter your passcode.
• Keep the phone unlocked. The accessibility tree can’t be read on a locked phone, and Mobster never enters a passcode. For long or scheduled tasks, lengthen Settings › Display & Brightness › Auto-Lock.
• Turn on a Focus mode for long runs, so a notification doesn’t take the foreground mid-task.
• One Mobster process per phone. The Mac app, mobster serve, mobster run --execute and the terminal UI each take the phone’s device lock, and a second one is refused while the first holds it.
• If the cable comes out, the task stops with “Your iPhone was unplugged. Plug it back in and try again.” Plug it back in and the runner restarts by itself.
• Let Mobster renew the runner. With a free Apple Account, Apple signs it for 7 days at a time. Mobster for Mac refreshes it while the phone is plugged in and unlocked, and mobster doctor says how many days are left.
• On a shared network, use the guided setup (mobster serve --manage-device, or Mobster for Mac), which applies every patch above, video port included.

Plug in your iPhone

$ curl -fsSL https://mobster.dev/install.sh | sh

Device setup walks through the USB setup from the CLI, and Troubleshooting lists each connection problem by what you see. Automate your own iPhone from a Mac shows what a task looks like once the phone is connected.