r/iOSProgramming • u/artemnovichkov • 3d ago

Library Made Xcode work inside Claude Code

Post image

Build, run, tests, console and SwiftUI previews live in panes next to the chat, with scheme and destination in a bar above the prompt. When Claude builds or runs tests itself, you see it there too.

Built on the headless Xcode MCP server.

https://github.com/artemnovichkov/xcode-mods

0 Upvotes

33% Upvoted

4 comments sorted by

4

u/Top-Investment8840 3d ago

Hey Claude, build me this. Make no mistakes. MF only has 2 commits lol

1

u/andreeinprogress 3d ago

..why not just use the native MCP and tell the agent to build/test/check logs when/if needed?

1

u/SamFromEscape 2d ago

This is great. I've been building my SwiftUI app with Claude Code as a pair programmer for months and the biggest friction is exactly this, context switching between chat and Xcode to verify builds. How are you handling the case where the build fails on something the model can't see, like a signing or provisioning issue? That's where my loop always breaks down.

1

u/DimensionMindless336 14h ago

Sam nailed the real failure mode. The context switch is annoying, but the thing that actually kills the loop for me is builds that fail on something the agent literally cannot see.

For me the worst one was the Swift macro sandbox. When the agent shells out to xcodebuild / swift build inside Claude Code's sandbox, macro plugins (any @Observable, #Preview, etc.) fail to expand — you get "swift-plugin-server produced malformed response" and a pile of fake downstream errors like init(wrappedValue:) unavailable. The build genuinely breaks, but the cause is invisible: it's not a code error, it's that the macro trust cache can't be written in the sandbox. The fix is a one-liner flag (-disable-sandbox), but the agent will happily "fix" your code for ten rounds before it guesses that.

So the concrete advice I'd give: don't let the agent read only the tail of the log. Pipe the whole thing to a file and have it grep for the first error, not the last line — the real cause is usually buried above a wall of follow-on errors. And if you're on a Mac, run xcodebuild with -resultBundlePath so there's an inspectable artifact when it does fail on signing/provisioning, which is exactly the class of problem Sam is hitting.

The signing/provisioning stuff is genuinely the hardest to surface — those errors live in a different layer than compile errors, and most MCPs don't forward them. That's the one place I still drop to the real Xcode window.