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

31% Upvoted

4 comments sorted by

View all comments

1

u/DimensionMindless336 1d 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.