A boilerplate has always been a download. You fill in a form or clone a repo, you get a project on disk, and from that moment the starter kit and your app drift apart. MCP changes the shape of that: instead of downloading a project, your AI agent calls the boilerplate as a tool, from inside the editor you are already working in, and gets back a real Xcode project plus the store setup that goes with it. The starter kit stops being a thing you fetch and becomes a thing your agent can do.
That sounds like a packaging detail. It is not. Once the generator is reachable over MCP, the agent knows exactly what it generated, the version you get is always the current one, and the parts of shipping a paid app that live outside your repository, App Store Connect products and RevenueCat configuration, happen in the same call as the code. This post covers what MCP is, the specific problems it fixes for boilerplates, what the Spaceport MCP server does, and the parts it honestly does not solve.
On this page
- What MCP actually is
- The problem with boilerplate-as-a-download
- Four things MCP changes
- What the Spaceport MCP server does
- MCP and skills do different jobs
- What MCP does not fix
- FAQ
What MCP actually is
MCP, the Model Context Protocol, is a standard way for an AI agent to talk to an external system. A server exposes a set of tools with typed inputs and outputs, the agent reads that list, and it calls the ones it needs. That is the whole idea. The value is that it is a standard: one server works in Claude Code, Cursor, Codex, Cline, and anything else that speaks MCP, without a per-editor plugin for each.
The mental model that helps is this. Without MCP, an agent can only do two things: edit files in your repository and run shell commands. Anything else, a dashboard, an API that needs a key, a service that knows something your repo does not, is outside its reach. It can write code about those things, and it does so blind. MCP is how you hand the agent a specific, bounded capability it did not have, with real inputs and a real result, instead of hoping it guesses correctly.
For a boilerplate, the capability you want to hand over is obvious: "generate this project, correctly configured, and set up the store side to match."
The problem with boilerplate-as-a-download
Every boilerplate, iOS or web, has the same four cracks. None of them are the boilerplate's fault; they come from the download being the delivery mechanism.
You leave your editor to use it. You open a browser, fill in a wizard, download a zip, unzip it, open it in Xcode, and only then start working. That context switch is small once and irritating every time after, which is why most people generate one project and then copy-paste it forever, carrying whatever was broken in it into every app they ship.
Your copy freezes on the day you downloaded it. The starter kit gets updated: a new iOS release changes an API, RevenueCat ships a new SDK major, Apple adds a required declaration. Your downloaded copy knows none of that. The boilerplate improves and your projects do not.
The agent does not know what it was handed. You point Claude Code or Cursor at the generated project and it starts by reading around, guessing at the architecture, and asking you where things live. It will happily add a second paywall next to the one already wired up, because it never saw the generation and has no idea which parts are load-bearing.
The non-code half stays manual. This is the big one on iOS. A generated Xcode project is maybe half of a shippable paid app. The other half is App Store Connect: the app record, the subscription group, the products, the price points in every territory, then the RevenueCat project, app, entitlement, offering, and packages that have to match those product IDs character for character. A zip cannot do any of that. It hands you code that is correct only if you go do the dashboard work yourself, and get every ID right.
That last crack is why AI agents help less than you would expect at the start of an iOS project. As covered in vibe coding a paid iOS app, the things an agent cannot do map almost exactly onto the things a boilerplate download leaves you holding.
Four things MCP changes
Put the generator behind an MCP server and each of those cracks closes for a fairly mechanical reason.
Scaffolding happens where you already are. You describe the app in the same conversation where you will build its first feature. No browser, no zip, no unzip. The practical effect is that generating a fresh project stops being a chore worth avoiding, so you stop copy-pasting last year's project into this year's app.
You always get the current generator. The server runs the latest version on every call. When iOS 27 lands or a dependency ships a breaking major, the fix lives in one place and everyone's next project has it. There is no "update your boilerplate" step, because there is no local copy of the boilerplate to update.
The agent gets structure, not prose. An MCP tool returns typed data: what was created, where it went, which modules are on, which product IDs were used. The agent starts with a map of the project instead of a folder it has to reverse-engineer. Ask for a new screen and it puts it in the right place, uses the paywall that is already wired, and matches the conventions the generator used, because it was told what those are rather than inferring them.
The dashboard work rides along in the same call. This is the part a download structurally cannot do. An MCP server holds credentials, so the same call that writes the Xcode project can also talk to the App Store Connect API and the RevenueCat API on your behalf: create the subscription group and products, set price points, create the RevenueCat project, app, entitlement, offering, and packages, and write the resulting identifiers into the generated code. The IDs match because one process produced both sides.
That fourth point is worth being blunt about. Mismatched product identifiers between your code, App Store Connect, and RevenueCat are the single most common reason a new paid app shows an empty paywall. It is not a hard problem, it is a transcription problem, and transcription problems disappear when one system writes both ends.
What the Spaceport MCP server does
Spaceport ships an MCP server, included in both tiers. You add it once to whatever agent you use:
claude mcp add spaceport -- npx -y @spaceport/mcpIt authenticates with the license key from your Spaceport dashboard, and connects your App Store Connect and RevenueCat credentials the same way the web dashboard does, so the server can act on your accounts. Other MCP clients take the same command in their own config format; the server does not care which agent is calling.
From then on, the flow is a conversation:
> scaffold a subscription app called Nimbus, bundle id com.deadpixel.nimbus
Select the modules to generate:
[x] RevenueCat subscriptions
[x] Onboarding and paywall
[x] Sign in with Apple
[ ] Sign in with Google
[ ] Firebase analytics
[x] AI assistant
[x] Notifications
[ ] Home screen widget
[ ] Apple Watch app
ok Nimbus.xcodeproj, opens and runs
App Store products created on your account
Under the hood the server exposes a small set of tools, and the agent picks among them: list the available modules and price tiers, create a project from a name and bundle ID and module selection, write it to a directory on your machine, and create the matching App Store Connect and RevenueCat configuration. The generated project is the same one the web dashboard produces: a SwiftUI app targeting current iOS, RevenueCatSubscriptionKit pre-wired, onboarding and paywall in place, a StoreKit configuration file for local testing, and the agent-facing files, CLAUDE.md, .cursorrules, and the Swift skills bundle, already at the root.
The useful part is what happens next. Because the agent made the call, it knows the app's module set, the file layout, and the exact product IDs it just created. Your first feature request lands in a project the agent already understands, on top of a store configuration that already matches. That is a different starting point from opening a downloaded zip and typing "have a look around."
You can still use the web dashboard for all of it. Some people prefer a form, and the wizard is not going anywhere. MCP is the same product reachable from the other side.
MCP and skills do different jobs
These two get conflated, so it is worth separating them cleanly.
Skills and rules files teach. A CLAUDE.md, an AGENTS.md, a .cursorrules, or a skills bundle is text the agent reads before it writes code. It shapes how the agent writes: @Observable instead of ObservableObject, foregroundStyle instead of foregroundColor, tests in Swift Testing, networking through your client. See AGENTS.md for iOS for how to write one well.
MCP acts. A tool call does something the agent could not otherwise do: reach an API, create a record on your account, generate a project from a maintained template.
A boilerplate wants both, and they compose. MCP creates the project and the store setup; the skills bundle that ships inside it keeps every later edit consistent with what was generated. Without the skills, the agent scaffolds a modern project and then fills it with 2021 SwiftUI. Without MCP, the agent writes beautiful, conventional code into a project it did not build and a store account it cannot touch. If you are driving all this from the terminal, Claude Code for iOS development covers how the agent and Xcode split the work.
What MCP does not fix
Being straight about the boundary is more useful than overselling the protocol.
- Signing and provisioning are still yours. Certificates, provisioning profiles, and your team setup live in Xcode and the developer portal. The generated project opens and runs; making it run on your device with your team is a step you take.
- App Review is still a human. Nothing about a tool call changes whether your app passes review, and a well-configured subscription is necessary but nowhere near sufficient.
- Real-device and real-purchase testing. Sandbox purchases on hardware need your device and your test accounts. A StoreKit configuration file covers the local loop, not the real one.
- The agent's code still needs review. MCP gives the agent better inputs and real capabilities. It does not make its judgment sound. Read the diffs.
- A tool call is still an action on your account. The server creates real products under your App Store Connect and RevenueCat credentials. That is exactly the point, and it is also a reason to know what you asked for before you approve it.
None of these are protocol problems and none of them will be solved by a better protocol. They are the parts of shipping an iOS app that are genuinely yours.
FAQ
What is MCP in simple terms?
The Model Context Protocol is a standard way for an AI agent to call an outside system. A server publishes tools with typed inputs and outputs, and any MCP-speaking agent, Claude Code, Cursor, Codex, Cline, can use them. One server, every editor, no per-tool plugins.
Why does a boilerplate need MCP at all?
Because a download can only give you files. An MCP server can also act on your accounts, so the same request that generates the Xcode project can create your App Store Connect subscription products and RevenueCat configuration, with identifiers that match the generated code by construction rather than by careful typing.
Does using MCP mean I cannot use the web dashboard?
No. The Spaceport MCP server and the web wizard produce the same project. Use whichever fits the moment: the dashboard when you want a form and a download, MCP when you are already in your editor and want to keep going.
Which agents work with the Spaceport MCP server?
Any MCP client. Claude Code, Cursor, Codex, and Cline are the common ones, and the setup is a single command or a few lines of config depending on the client.
Is MCP a replacement for CLAUDE.md or AGENTS.md?
No, they solve different halves. Rules and skills files teach the agent your conventions before it writes code. MCP gives it capabilities it does not have. A good starter kit ships both, which is why the generated project contains the agent files and the generator itself is reachable as a tool.
Can the MCP server create my App Store products?
Yes, that is the main reason it exists. With your App Store Connect and RevenueCat credentials connected, generating a project also creates the subscription group, products, price points, and the matching RevenueCat project, app, entitlement, offering, and packages.
Does this mean the agent can ship my app for me?
It means the agent can get you a real, buildable, store-configured starting point without you leaving the editor. Signing, device testing, App Review, and every product decision after that are still yours.
Spaceport generates a production-ready SwiftUI Xcode project with the paid-app foundation already wired: onboarding, Apple and Google sign-in, RevenueCat subscriptions, Firebase analytics, an AI assistant, notifications, a home screen widget, and an Apple Watch app. It sets up your subscription products and pricing in App Store Connect and RevenueCat through their APIs, and it does all of it either from the web dashboard or from your editor through the Spaceport MCP server. From an indie iOS dev, for indie iOS devs.