The Development Loop

The core build-run-screenshot-fix cycle that makes AI-assisted Apple development work. Claude Code writes Swift, XcodeBuildMCP builds and runs it, screenshots the result, and Claude Code iterates — all without manual intervention.

When to use

Use when writing or modifying SwiftUI views, debugging layout issues, verifying user flows, or any time Claude Code needs to see what the app looks like on any Apple platform simulator.

The pattern

The cycle

1. Write code. Claude Code creates or modifies .swift files. For UI work, this means SwiftUI views, modifiers, and state. Claude Code has full read/write access to all Swift source files.

2. Build and run. XcodeBuildMCP's simulator/build-and-run builds the project and launches it in the simulator. If there are compiler errors, Claude Code sees them directly in the tool response and can fix them immediately.

3. Screenshot. simulator/screenshot captures the current simulator screen. Claude Code sees the image and can assess layout, spacing, colors, typography, and content correctness.

4. Inspect. For deeper analysis, ui-automation/describe-all returns the full accessibility tree — element types, labels, positions, and hierarchy. This is more reliable than guessing from the screenshot alone.

5. Interact. For multi-step flows (tapping buttons, entering text, navigating between screens), UI automation tools simulate real user input:

• ui-automation/tap — tap at coordinates
• ui-automation/type — type into the focused field
• ui-automation/swipe — swipe between coordinates

Claude Code can walk through a complete user flow, screenshotting at each step.

6. Fix and repeat. Based on what Claude Code sees, it modifies the code and loops back to step 2. This continues until the feature works correctly.

Testing across platforms

Change the simulatorName in .xcodebuildmcp/config.yaml to test on different devices: iPhone 16, iPad Pro 13-inch, Apple Watch Series 10 - 46mm, or target macOS directly. SwiftUI layout adapts automatically, but it's worth screenshotting on each target to catch platform-specific issues like sidebar behavior on iPad vs. stack navigation on iPhone.

Handling compiler errors

The Swift compiler is strict — especially with SwiftUI's type system. Complex view expressions can trigger "expression too complex" errors or slow builds. When this happens:

• Break large view bodies into smaller extracted sub-views
• Add explicit type annotations to help the type checker
• Move complex logic out of the view body into computed properties or methods

Claude Code is generally good at interpreting Swift compiler errors and fixing them. Feed the full error output back and let it iterate.

Example prompt

Build and run MyApp on iPhone 16. Take a screenshot. Then navigate to the Settings tab, toggle the dark mode switch, and take another screenshot. Then switch to the iPad Pro simulator and screenshot the same screens so I can compare the layouts.

Trade-offs

• Claude Code writes UI code without seeing it until after a build — the feedback loop is fast but not instant like a hot-reload
• Screenshots show pixels but not interactive state — use describe-all to understand element hierarchy when the screenshot is ambiguous
• Coordinate-based tapping can be brittle if the layout changes between iterations — always use describe-all to find current element positions
• watchOS and tvOS simulators have more limited UI automation support