Automating an Android phone is a solved problem. You plug it in, turn on USB debugging, and adb will tap, type and swipe for you forever. Automating an iPhone is not that. There is no adb, no shell, and no supported way for one app to touch another.
It is still possible — we drive one from NOISEY every day — but the route is narrow and the constraints are worth understanding before you spend a weekend on it.
The only sanctioned route is a test runner
Apple does permit one app to drive another, but only under the guise of UI testing. The tool is WebDriverAgent — an XCTest bundle, originally from Facebook and now maintained by the Appium project, which you build and install onto the phone. Once it is running it exposes an HTTP API: ask it for the screen, tell it where to tap.
The Mac talks to the phone over usbmuxd, Apple's own USB multiplexing daemon — the same thing Finder and Xcode use. On top of that sits the runner, and the runner does the tapping. Nothing here is a hack or a jailbreak; every piece is Apple's own developer tooling used for its stated purpose.
Developer Mode, and the cable
On iOS 16 and later the phone must have Developer Mode switched on: Settings → Privacy & Security → Developer Mode, then a restart. The toggle only appears after a Mac with Xcode has talked to the phone at least once, which catches people out — if you cannot find it, plug the phone in first.
Two more things that waste an afternoon if you do not know them. A charge-only cable looks identical to a data one and the Mac simply never sees the phone; if idevice_id -l prints nothing, suspect the cable before the software. And set Auto-Lock to Never — a phone that sleeps mid-run kills the runner underneath you, and the failure looks like a bug in your automation rather than a screen that went dark.
Read the screen; do not guess at pixels
The temptation is to record coordinates and replay them. It works immediately and it is a trap. A tap at (645, 1398) means "that spot", not "that button" — so the moment a notification banner pushes the row down, or you run the same script on a phone with a different screen, you are tapping the wrong thing.
Worse, you never find out. Injecting a tap at a coordinate always succeeds; there is no such thing as missing.
WebDriverAgent will hand you the accessibility tree — every element on screen with its label, type and position. Find the button by name, then tap its centre. It is slower to write and it is the only version that survives contact with a real phone.
The tree has a cost
Asking for the whole tree is not free. On a simple screen it returns in under a second. On an app with a deep view hierarchy it can take twenty seconds and return several megabytes — and unbounded, on the worst offenders, it simply never returns at all and the connection resets.
The fix is to bound how deep the snapshot walks. Shallow reads are fast and usually complete; go deeper only when the shallow read came back with too little to act on.
The wall: you cannot do this for other people
This is the part that decides whether iPhone automation is a hobby or a product. WebDriverAgent is a test runner, not an app. It has to be signed with a provisioning profile that names the specific device it will run on.
Your certificate cannot cover a stranger's iPhone. TestFlight does not distribute XCUITest runners for third-party automation. The Enterprise programme is for employees, and Apple terminates accounts used to route around that. Device farms manage it only because they own the hardware.
So: automating your own iPhone, or phones your organisation owns and has enrolled, is entirely achievable. Shipping iPhone automation to customers as a self-serve feature is not, and anyone claiming otherwise is either wrong or about to lose an account.
What this looks like in NOISEY
We treat the iPhone as a founder-and-agency tool rather than a consumer feature, for exactly the reason above. The desktop app checks the whole chain for you — Xcode, the iOS platform package, a signing team, the WebDriverAgent checkout, Developer Mode, the cable — and tells you which step is missing in the words you need to fix it, rather than failing with a stack trace.
Everything after that is the same as Android: routines describe what a phone does, automations decide when, and the phone in front of you does the work.