Debug in iOS simulator

Give Codex the whole simulator loop

This use case works best when Codex owns the full loop: choose the right app target, launch the app in Simulator, inspect the current screen, perform the reproduction steps, gather logs and screenshots, inspect a stack trace if needed, patch the code, and rerun the same path to prove the bug is gone.

Use the Build iOS Apps plugin when you want that loop to stay agentic. Its iOS debugger workflow is built around XcodeBuildMCP, which means Codex can interact with a booted simulator and gather the same evidence a human would normally collect by hand.

When XcodeBuildMCP is configured with simulator automation, UI automation, debugging, and logging workflows, Codex can own the full reproduce-debug-verify loop. If Codex has not picked a project, scheme, and simulator yet, ask it to discover those first and reuse that setup for the rest of the session.

Leverage what XcodeBuildMCP can do

These are the practical capability groups to prompt Codex to use:

• Project and simulator discovery: check whether Codex already knows which app target and simulator to use, discover the Xcode project or workspace, enumerate schemes, find or boot a simulator, and keep that setup stable for future build/run steps.
• Build and launch control: build the active app target, install and launch the simulator build, relaunch with log capture when needed, and resolve the app bundle id if Codex needs to inspect app-specific runtime logs.
• UI inspection and interaction: read the on-screen accessibility hierarchy, take screenshots, tap controls, type into fields, scroll through lists, and perform edge swipes or other simulator gestures.
• Logs and debugger state: stream simulator logs, attach LLDB to the running app, set breakpoints, inspect stack frames and local variables, and run debugger commands when a crash or hang needs deeper inspection.

The key habit is to ask Codex to inspect the view tree before it taps. XcodeBuildMCP exposes the accessibility hierarchy plus coordinates, so Codex can prefer stable labels or element IDs instead of guessing raw screen positions.

Turn a vague bug into a reproducible script

The iOS debugger skill is most effective when your prompt gives one concrete bug and one expected outcome, then lets Codex drive the app and collect evidence autonomously. If a login, deep link, or test fixture is required, say that once and ask Codex to pause only when that missing input blocks progress.

Practical tips

Ask for evidence, not just a fix

Request the exact simulator, scheme, screenshots, log snippets, and stack details that Codex used to explain the bug. That makes the final patch much easier to review than “I think this should fix it.”

Prefer accessibility labels over coordinates

If Codex has to tap by coordinates because a control has no stable label or accessibility identifier, ask it to call that out. That is often a signal that the bug fix should include a small UI testability improvement too.

Keep one bug per run

A simulator-driven debugging loop is powerful, but it is still easier to trust when one prompt targets one failure mode. Ask Codex to finish one reproduce-fix-verify cycle before expanding to adjacent issues.