Automate iOS App Debugging on Simulators
iOS Debugger Agent uses XcodeBuildMCP to build, run, interact with, and log an iOS app on a booted simulator.
Why it matters
Streamline your iOS development process by automating the build, run, and debugging of your applications on simulators. Interact with your app's UI, capture logs, and inspect elements without manual intervention.
Outcomes
What it gets done
Build and run iOS apps on simulators using XcodeBuildMCP.
Automate UI interactions like tapping, typing, and gestures.
Capture and analyze runtime logs and console output.
Inspect UI elements and take screenshots for debugging.
Install
Add it to your toolbox
Run in your project directory:
curl -fsSL https://spark.entire.vc/get/ag-ios-debugger-agent | bash Overview
iOS Debugger Agent
Builds, runs, interacts with, and captures logs from an iOS app on a booted Simulator using XcodeBuildMCP tools for scheme setup, UI interaction, and log capture. Use when running, debugging, or inspecting an iOS app on a simulator via XcodeBuildMCP.
What it does
iOS Debugger Agent uses XcodeBuildMCP to build and run the current project scheme on a booted iOS simulator, interact with the UI, and capture logs, preferring the MCP tools over manual commands for simulator control, logs, and view inspection.
The core workflow runs in sequence unless a narrower action is requested. First, discover the booted simulator via mcp__XcodeBuildMCP__list_sims, selecting the device in Booted state - if none is booted, ask the user to boot one rather than booting automatically. Second, set session defaults via mcp__XcodeBuildMCP__session-set-defaults with the project or workspace path, the app's scheme, the booted simulator ID, and optionally configuration: "Debug" and useLatestOS: true. Third, build and run when requested via mcp__XcodeBuildMCP__build_run_sim - if the build fails, check the error output and retry (optionally with preferXcodebuild: true) or escalate to the user before any UI interaction; after a successful build, verify the app actually launched via describe_ui or screenshot before proceeding. If the app is already built and only a launch is needed, use launch_app_sim instead; if the bundle ID is unknown, resolve it via get_sim_app_path then get_app_bundle_id.
For UI interaction and debugging: describe_ui before tapping or swiping to know what's on screen, tap (preferring element id or label over raw coordinates), type_text after focusing a field, gesture for common scrolls and edge swipes, and screenshot for visual confirmation. For logs and console output: start_sim_log_cap with the app's bundle ID to begin capture, stop_sim_log_cap to end it and summarize the important lines, and setting captureConsole: true (with a relaunch if required) for console output specifically.
Troubleshooting guidance: on a build failure, ask whether to retry with preferXcodebuild: true; if the wrong app launches, confirm the scheme and bundle ID match expectations; if UI elements aren't hittable, re-run describe_ui after any layout change since element positions may have shifted.
When to use - and when NOT to
Use this skill when the user asks to run, debug, or inspect an iOS app on a simulator, or needs simulator UI interaction, screenshots, or runtime logs via XcodeBuildMCP. Do not treat the output as a substitute for environment-specific validation, testing, or expert review, and stop to ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.
Who it's for
iOS developers who want to build, run, interact with, and debug an app on the iOS Simulator through XcodeBuildMCP tooling instead of manually driving Xcode and Simulator by hand.
FAQ
Common questions
Discussion
Questions & comments ยท 0
Sign In Sign in to leave a comment.