Vibecoding Apple apps
Shipping macos/iOS automation without learning Swift
2026-05-04 — 2026-05-27
Wherein Two MCP Servers Are Set to Work in Concert — One for the Build Engine, One for the Running IDE — So That Personal iOS Applications May Be Constructed Without Swift Being Learnt
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, in that 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.
On dogma: the App Store and the various fights about App Review are irrelevant to me, since the apps I’m writing are for me. Traditionally people fulminate at this point about how Apple development is expensive. I am resigned to paying Apple their 99 pieces of silver per year in Apple Developer fees for the privilege of running my own code on my own phone. It seems fine. In fact I don’t 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+agent combo kinda worked for ages, but it was pretty noisy and slow. Recent Xcode updates (I think 26.3) made it way better. The agent no longer needs to strain 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; apparently this is the standard way to make LLM-friendly dev tools. xcodebuild is famously verbose.1
2 Preliminaries
Run the following to install Xcode or just the command line tools:
Xcode’s command-line tools sometimes break after updates. The current incantations to fix them are:
3 XcodeBuildMCP
An open-source workhorse MCP with ~80 tools.
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 and structured parseable return data from each.
The repo is at cameroncooke/XcodeBuildMCP. Found via Blake Crosley’s setup post.
Even without opening 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”.
4 Apple’s MCP bridge
Ships with Xcode 26.something — 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 UI, not just the code that produced it, and can iterate visually.
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.
5 Division of labour
XcodeBuildMCP implements the build–test–debug loop. Apple’s MCP implements all the “GUI stuff” IDE-layer awareness — diagnostics, docs, previews. It seems we should run both.
| 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 | ✅ | ❌ |
6 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.
Enough for the agent to default to the right tool without me re-hinting it on every prompt.
7 In-IDE Claude
Xcode 26.3+ ships with a Claude Agent panel built into the IDE, using the same Agent SDK and roughly the same ~20 tools as xcrun mcpbridge. Go to Settings → Intelligence, drop in an Anthropic API key.
I do not use this. I live in the terminal, and Claude Code is where I develop every other bloody thing, and my Apple vibecoding projects are not significant enough to justify a shift. Also I spent about 15 seconds looking for the agent panel as per the instructions and didn’t find it, and I left, bored. YMMV
8 Loose ends
8.1 Signing and provisioning
Even with the ($) developer account, the rituals of personal devices, free/paid teams, provisioning profiles, capabilities, and the keychain are confusing and change in every release. MCPs do not seem to abstract this away, at least not for me. Perhaps there is no abstraction over it because Apple would rather have a human somewhere in the loop to sign off on their nonsense.
8.2 Putting my custom apps on my friend’s devices
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 haven’t committed. Probably TestFlight.
8.3 SwiftUI Preview, is it good?
Does the automated UI capture actually close the loop? In principle, the agent sees the preview and iterates. In practice I’m 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.
8.4 All the system APIs
Core Data, HealthKit, Shortcuts intents, WidgetKit — these are not as well attested on the internet as Python, and the API keeps shifting. I note that Claude frequently resorts to defunct APIs and deprecated patterns. How annoying is this in practice?
8.5 Disk hungriness
Oh noes, Xcode is gigantic and it fills up my backup drive! What to do?
sudo tmutil addexclusion -p /Applications/Xcode.app
sudo tmutil addexclusion -p ~/Library/Developer/Xcode/DerivedData
sudo tmutil addexclusion -p ~/Library/Developer/CoreSimulator
sudo tmutil addexclusion -p ~/Library/Developer/Xcode/iOS\ DeviceSupport
sudo tmutil addexclusion -p ~/Library/Developer/Xcode/watchOS\ DeviceSupport
sudo tmutil addexclusion -p ~/Library/Developer/Xcode/visionOS\ DeviceSupportTODO: should I also exclude these from spotlight?
9 Shortcuts
viticci/shortcuts-playground-plugin
Shortcuts Playground: A Claude Code and Codex plugin for building, validating, signing, and remixing macOS/iOS Shortcuts with natural language.
10 Usable scripting
Apple has shipped a slow, incomprehensible scripting language for as long as I can remember. It’s called AppleScript. After spending a long time trying to persuade it to do things, I’m comfortable saying it will never save me time if I write it by hand, although I do occasionally run a one-liner via osascript. There are attempts to, in principle, open up macOS’s scripting APIs to, e.g., JavaScript via jstalk or Python via PyObjC, but that’s brutally low level unless we’re app developers, and the documentation is even worse. If we’re writing apps, why not just use Swift?
Some people have converged on the UIKit accessibility API as a reasonable scripting interface.
On this front, try Hammerspoon/Phoenix. pyatomac does the same for Python but seems designed for UI testers, not UI users. You can do it with AppleScript of course, if your heart overflows with bituminous hate.
Or— vibe-code a Swift app instead? See above
Footnotes
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.↩︎