Debug an iOS app with AI: what actually works

The short answer

An AI agent needs three things to debug an iOS app: a way to build and launch it, a way to drive its UI, and a way to see what the app did internally — the requests it sent, the logs it wrote, the rows it stored. Today's tooling covers the first two well and the third almost not at all. Build servers automate Xcode. UI-automation servers replay taps through the accessibility tree. Only an in-app SDK reports runtime state, and it costs one dependency in your debug build. Most teams end up combining two of the three.

These three overlap less than their descriptions suggest. The matrix below is the part nobody publishes.

The tool matrix

Seven tools an AI agent can point at an iOS app, and the nine questions that decide which one you need. Two rows are ours to lose — they are in the table, not in a footnote.

Checked 20 August 2026 against each project's own documentation. All of them ship fast; verify before you commit to one.

How to read it

The last two rows are the trade. Every tool that needs nothing from your app is also blind to everything inside it — an accessibility tree cannot tell you that the feed is empty because /v2/feed returned 500 with a malformed body. An SDK can, because it lives on the same side of the network stack as your code. That is the whole bargain. It also means the two categories are complements, not competitors — building with XcodeBuildMCP and observing with AppTelepath in the same session costs nothing but two MCP entries.

Making the agent verify its own change

Compiling is not verifying. The loop that actually closes is: build, install, launch, navigate to the screen you touched, then ask what broke. The first three steps belong to an Xcode-side server. The last one is where agents stall and ask you for a screenshot.

telepath_screen_digest answers it in text: the current view controller, the visible copy, and every interactive element with a stable ref. Cheaper than an image and directly actionable — the agent taps by ref, never by guessed coordinates. telepath_tap then returns what changed plus the error logs and failed requests recorded during that tap, so a step that worked needs no follow-up call at all.

# the agent already built and launched the app
telepath_screen_digest
// current screen as text, with refs

telepath_tap       { "ref": "s4n7" }
// tap by ref; the response carries the consequences

telepath_diagnose
// anything wrong in the last 60 seconds?

telepath_diagnose returns one severity, one headline, deduplicated error-log clusters, failed and slow requests, crashes and hangs — the whole "what just went wrong" question in a single call, ranked. Fed a clean result, the agent moves on; fed an error cluster, it has the stack it needs.

Reproducing a bug that only happens on a real device

Real cellular, real thermal throttling, a real keyboard, a build that came out of CI — plenty of bugs never appear in a simulator. This is exactly where local tooling gets expensive: WebDriverAgent installed on the device, a tunnel process, a cable, and a Mac in the same room as the phone.

AppTelepath inverts the direction. The SDK opens an outbound WebSocket from the device to the hosted service, so the device needs network and nothing else. The agent connects to the hosted MCP endpoint. Neither has to be near the other — a tester's phone in another country is one telepath_list_devices call away, and the same is true of a simulator on a colleague's Mac.

# one call each; no cable, no tunnel
telepath_list_devices    // every device attached to the workspace
telepath_simulate        // weak network, GPS route, push — including denied states
telepath_repro           // record, act, stop, summarized timeline — one call
telepath_crash_reports   // crashes with stacks

Stripped Staging builds do not resolve their own symbols, and a debugger that invents a nearby symbol name is worse than one that admits it cannot. Unresolved frames come back as image offsets together with the image UUIDs and load addresses, so the agent symbolicates locally, where the dSYM already is:

# the agent has a shell; let it use one
atos -o MyApp.app.dSYM/Contents/Resources/DWARF/MyApp \
  -arch arm64 -l 0x1044b8000 0x1044c9a1c

Where AppTelepath stops

A comparison page whose author wins every row is not a comparison page.