Vibecoding Apple apps

Shipping macos/iOS automation without learning Swift

2026-05-04 — 2026-05-04

Wherein two MCP servers are employed to grant a language model structured access to the Xcode toolchain, permitting iOS applications to be built, tested, and debugged without Swift being learned by the author.

faster pussycat

making things

diy

code

apple

workflow

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. The kind of automation that ought to be a 50-line shell script, except the phone does not run shell scripts, so it has to be an app.

I have not learned Swift, and I am not going to. iOS development looks, from the outside, like a stack of arbitrary ceremony around what should be a small program. The App Store and the various fights about App Review are also irrelevant to me, since the apps I am writing are for me. I am happy to pay Apple their USD $99/year for the privilege of running my own code on my own phone,¹ and that is the end of my engagement with the Apple platform business model.

What I do want is for the LLM to do the Swift for me, and the means by which this becomes tolerable is the recent crop of MCP servers that hand the LLM structured access to the Xcode toolchain. This is a cousin to general code-assistant practice. Here I specialise on Apple gizmos.

tl;dr Two MCP servers, run both:

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. The first is the build engine; the second is the IDE eyes-and-ears.

1 Why this works now

The shift is that the LLM no longer parses 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.²

2 XcodeBuildMCP

Open-source, ~80 tools, the workhorse.³ Install:

claude mcp add xcodebuildmcp -- npx -y xcodebuildmcp@latest

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, 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:

claude mcp add xcode -- xcrun mcpbridge

Around 20 tools, all hanging off a running Xcode. File ops in the editor, real-time diagnostics from the live build context, Apple documentation search, a Swift REPL, and — the bit I find most useful — 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 open, so it is 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 The split

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:

## XcodeBuildMCP integration
- Build: mcp__xcodebuildmcp__build_sim_name_proj
- Test:  mcp__xcodebuildmcp__test_sim_name_proj
- Platform: iOS, Swift 6, SwiftUI, MVVM + @Observable

Enough for the agent to default to the right tool without me re-hinting it on every prompt.

6 Xcode 26.3+ gives us 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, done.⁴

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, it is presumably a nicer experience than the dual-MCP setup.

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; it is a substance. Apple would rather a human signed 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.
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. To be tested.
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 not so much, I assume. We shall see.

I will update this entry as I learn more. Its job for now is to record the current shape of the toolchain, since this corner of the LLM-coding ecosystem is moving fast and a snapshot is useful to set up each new project.

Footnotes

In fact I do not even need to, but it gets tedious fast to avoid the fee. Long story.↩︎
I am told the xcodebuild log 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.↩︎
All of which 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.↩︎
See a walkthrough on YouTube.↩︎