Vibecoding Apple apps
Shipping macos/iOS automation without learning Swift
2026-05-04 — 2026-05-16
Wherein Two Complementary MCP Servers Are Pressed Into Service, One for Headless Builds and One for IDE Diagnostics, So That Personal iOS Utilities May Be Assembled Without the Writing of Swift
I want my phone to do small useful things for me — tally a thing I notice, nag me when I haven’t stretched, watch a sensor and remind me when something changes, that kind of thing. That kind of automation ought to be a 50-line shell script, except the phone is not a Protestant device. It does not permit a personal relationship with the silicon. Instead my relationship is mediated by the rite of XCode, in the approved forms, the correct vestments, the sacred language.
I have not taken holy orders in Swift, and I am not going to. The iOS catechism looks, from outside, like elaborate liturgy wrapped around what should be a small blessing. What I need is an Electric Monk — a labour-saving device that handles the sacraments on my behalf.
Claude might just be that Monk.
Speaking of dogma: the App Store and the various fights about App Review are irrelevant to me, since the apps I am writing are for me. Traditionally people rant at this point about how Apple development is expensive. I am resigned to paying Apple their USD $99/year Apple Developer fee for the privilege of running my own code on my own phone — in fact I do not technically need to pay just to run code, but it gets tedious fast without signing the binaries, so whatever. It is more expensive than $0, but the time saving dwarfs it so, like, fine. I agree that it is annoying but it is not the worst. When Apple gets too creepy, I will switch to Linux and then I will have another long list of annoyances to complain about with the free toolchain there.
tl;dr There exist two MCP servers— I run both, which seems to work.
- XcodeBuildMCP — headless wrapper around
xcodebuild/simctl/LLDB. Builds, tests, runs, debugs. Works with Xcode closed. xcrun mcpbridge— Apple’s own bridge into the running Xcode IDE. Live diagnostics, Apple docs lookup, SwiftUI Preview capture.
They do not AFAICT overlap, or at least Claude seems to know which to use. The first is the build engine; the second is the IDE eyes-and-ears.
1 It works now
The Xcode build kinda worked for ages, but it was pretty noisy and slow. Recent Xcode updates (I think 26.3) made it way better. The LLM no longer needs to parse xcodebuild log spew to figure out what went wrong. It calls a tool, gets back JSON with the file, line, column, and message of each error, and acts. The same shift previously made gopls, pyright, tsc --watch etc. workable inside agent loops. iOS got there later, partly because Apple, and partly because xcodebuild is famously verbose.1
2 XcodeBuildMCP
An open-source workhorse MCP with ~80 tools. All of this assumes xcode-select and the underlying CLI tools are behaving themselves on the day. They frequently are not; see macos_hacks for the standing repair manual.
Install:
It covers structured builds, test runs with per-method results, simulator boot/shutdown/install, real-device deployment, LLDB-driven debugging, and SwiftPM in addition to .xcodeproj/.xcworkspace. All returning tidy JSON.
The repo is at cameroncooke/XcodeBuildMCP. The clearest write-up I’ve found is Blake Crosley’s setup post, which is also where I cribbed most of my mental model.
Even if I never open Xcode-the-IDE, this MCP gets me from “Claude wrote some Swift” to “Claude built it, ran it on the simulator, ran the tests, and saw which ones failed”.
3 Apple’s MCP bridge
Ships with Xcode 26 — no separate install, only an enable step:
Around 20 tools, all interfacing with a running Xcode GUI IDE — file ops in the editor, real-time diagnostics from the live build context, Apple documentation search, a Swift REPL, and SwiftUI Preview capture. The agent gets to see the rendered preview of a view, not just the code that produced it, and can iterate visually. Anthropic’s announcement post has more detail.
This one only works with Xcode running, so it’s no use for headless CI. For the kind of work I’m doing — sitting at the laptop, iterating on a small app — having Xcode open is not a hardship.
4 Division of labour
XcodeBuildMCP owns the build–test–debug loop. Apple’s MCP owns IDE-layer awareness — diagnostics, docs, previews. Run both. The author of the setup write-up does, I copied that, and it works.
| XcodeBuildMCP | xcrun mcpbridge |
|
|---|---|---|
| Install | npx xcodebuildmcp@latest |
bundled with Xcode 26 |
| Xcode open? | not required | required |
| Build / test / run | ✅ | ❌ |
| SwiftUI Previews | ❌ | ✅ |
| Apple docs | ❌ | ✅ |
| LLDB | ✅ | ❌ |
| CI / headless | ✅ | ❌ |
5 Project CLAUDE.md
A short hint at the top of the project’s CLAUDE.md keeps the agent from rediscovering the toolchain on every turn. Mine looks roughly like:
Enough for the agent to default to the right tool without me re-hinting it on every prompt.
6 In-IDE Claude
Xcode 26.3+ also ships with a Claude Agent panel built into the IDE, using the same Agent SDK and roughly the same ~20 tools as xcrun mcpbridge. Settings → Intelligence, drop in an Anthropic API key.2
I do not use this. I live in the terminal, and Claude Code is where my prompts, my git worktree workflow, and my muscle memory live. Also I spent about 15 seconds looking for the agent panel and didn’t find it, so I left, bored. For somebody whose centre of gravity is Xcode itself, might be worthwhile?
7 Loose ends
A scattered list of things I have not yet figured out, or have figured out and disliked.
Signing and provisioning. Even with the developer account paid up, the rituals around personal devices, free/paid teams, provisioning profiles, capabilities, and the keychain are exactly as user-hostile as everyone says. I have not yet found an MCP that abstracts this away. I suspect there is no abstraction over it because Apple would rather a human was somewhere in the loop to sign off on their nonsense.
Sideload vs. dev-install. For my own apps on my own phone, the dev-account install with a 1-year cert is fine. For apps I might want to give to one or two friends, the answer is less clear. AltStore? TestFlight? I have not committed. Probably TestFlight.
Does SwiftUI Preview capture actually close the loop? In principle, the agent sees the preview and iterates. In practice I am not yet sure how well this scales past a single isolated view. View hierarchies, state, mock data, navigation contexts — all of these complicate the preview. Currently I plan to avoid ever finding this out by just not building anything complicated enough to need it.
Non-trivial system integrations. Core Data, HealthKit, Shortcuts intents, WidgetKit — the bits I actually want to use, since they are what makes the phone useful as an automation target. The simple-Swift-app-with-a-button pattern is well-trodden in LLM-generated examples. The “talk to HealthKit and surface a daily nudge” pattern… maybe? TODO
8 disk hungriness
oh noes Xcode is gigantic and it fills up my backup drive! What to do?
tmutil addexclusion -p /Applications/Xcode.app
tmutil addexclusion -p ~/Library/Developer/Xcode/DerivedData
tmutil addexclusion -p ~/Library/Developer/CoreSimulator
tmutil addexclusion -p ~/Library/Developer/Xcode/iOS\ DeviceSupport
tmutil addexclusion -p ~/Library/Developer/Xcode/watchOS\ DeviceSupport
tmutil addexclusion -p ~/Library/Developer/Xcode/visionOS\ DeviceSupportFootnotes
I am told the
xcodebuildlog volume on a clean build of a non-trivial app is measured in megabytes. Certainly if I leave debug logging on, my iPhone storage goes to 0 fast.↩︎