Vibe coding a paid iOS app, building it mostly by prompting an AI agent instead of writing the code by hand, works for a surprising amount of the app and hits a hard wall on specific parts. The agent can write your SwiftUI views, wire up features, and refactor as you go. It cannot click through App Store Connect, make code signing work, judge whether your paywall converts, or guarantee your app passes review. Knowing exactly where that line sits is what keeps you from expecting the agent to ship the whole thing and getting stuck a week before launch.
This guide maps the line honestly: what an agent genuinely does well on an iOS app, what it cannot do no matter how you prompt it, the parts that look like code but bite because they have to match a dashboard, and the workflow that gets the most out of vibe coding without pretending it does everything.
On this page
- What vibe coding means for iOS
- What the agent does well
- What the agent can't do
- The parts that look like code but bite
- A workflow that actually works
- Where a starter kit fits
- FAQ
What vibe coding means for iOS
Vibe coding is letting an AI agent write most of the code while you steer with prompts, review, and course corrections. On the web it can feel like the agent builds the whole thing, because a web app is mostly code plus a deploy. iOS is different: a shippable paid app is code plus a stack of non-code steps that live in Apple's tools, not your editor.
That is the key mental shift. The agent operates in your repository. A lot of shipping an iOS app happens outside the repository, in App Store Connect, in the signing and certificates system, in Xcode's runtime, and in App Review. The agent is excellent inside its half and blind to the other. Vibe coding works when you use it for the first half and own the second yourself.
What the agent does well
Inside the code, a modern agent is genuinely strong, especially on a well-structured project.
- SwiftUI views and screens. Describe a screen and it builds it, wires the state, and iterates when you say what is off.
- Features and flows. A settings screen, a list with search, an onboarding sequence, the agent assembles these quickly from a clear description.
- Refactors. Renaming, extracting components, threading a new dependency through, the mechanical changes that are tedious by hand.
- Wiring modules together. Connecting your networking layer, a view model, and a view, or hooking a button up to an action.
- Tests. Writing unit tests for logic you describe, and running them if it can build.
- Boilerplate. The repetitive scaffolding that is the same in every app and worth none of your time.
Give it your conventions and a project that builds from the command line, and it can run a tight loop of write, build, fix without waiting on you. That is where vibe coding earns its keep.
What the agent can't do
These are not prompt problems. They are outside the agent's reach entirely, and no amount of rewording changes that.
- App Store Connect setup. Creating your app record, subscription products, pricing, and store metadata happens in Apple's dashboard or through an API with your credentials. The agent cannot log in and click through it.
- Signing, certificates, and provisioning. Getting a build to run on a device or ship to the store depends on your Apple Developer account, certificates, and profiles. This is account-level Apple machinery the agent has no access to.
- Seeing the running app. The agent cannot look at the screen. It does not know if a layout is cramped, an animation stutters, or a color is wrong. Visual and interaction judgment is yours.
- App Review compliance. Whether your app passes review depends on Apple's guidelines and a human reviewer. The agent can follow known rules if you tell it, but it cannot guarantee an outcome or read Apple's mind.
- Real-device and real-purchase testing. Testing an actual purchase, a push notification on a real phone, or performance on older hardware needs a device and accounts the agent does not have.
- Product and design decisions. What to build, what to charge, how the onboarding should feel, these are judgment calls, and the agent is a tool for executing them, not making them.
The parts that look like code but bite
The confusing cases are the ones that are in the repository but only work if they match something outside it. The agent can write the code and still leave you broken, because the truth lives in a dashboard.
- Subscription and StoreKit config. The agent can write a paywall, but the product IDs in the code have to match products you created in App Store Connect and, if you use it, RevenueCat. Mismatched IDs mean an empty paywall, and the fix is in the dashboards, not the code.
- Entitlements and capabilities. Sign in with Apple, push notifications, App Groups, these need both code and a matching capability enabled on your App ID. The agent can add the code and miss the capability.
- The Xcode project file. The agent can corrupt the dense
project.pbxprojwhen adding files or targets. It looks like editing text; it is editing machine-managed state. - The privacy manifest and permission strings. Apple requires specific declarations and usage strings. The agent can write plausible ones, but getting them right and complete is on you.
The pattern is the same across all of these: the code is necessary but not sufficient, and the agent only sees the code.
A workflow that actually works
The setup that gets the most from vibe coding splits the work along that line.
You own the outside-the-repo parts once, at the start: the Apple Developer account, signing, the app record, the subscription products and their pricing, the capabilities your app needs. With those in place, you hand the agent a project that already builds, and let it run on features. It writes screens and logic, builds from the command line to check itself, and you review the diffs and glance at Xcode to judge how the running app looks. When something is a config mismatch rather than a code bug, you fix it in the dashboard.
Giving the agent clear conventions makes this dramatically smoother, since it stops guessing at patterns and stops producing code you have to unwind. For that, see AGENTS.md for iOS and, for driving the agent from the terminal alongside Xcode, Claude Code for iOS development.
Where a starter kit fits
Look at the list of things the agent cannot do and you will notice it is almost exactly the list of things that make starting a paid iOS app slow: the App Store Connect setup, the subscription and pricing configuration, the entitlements, a project that is signed and builds. These are the parts vibe coding leaves you to do by hand, and they are the least fun and most error-prone part of the whole thing.
That is the gap a starter kit fills. It does the non-code, outside-the-editor setup once, so the agent has a real, wired, buildable app to work on from the first prompt instead of a blank project and a week of dashboard clicking. Vibe coding is far more pleasant when the foundation the agent builds on is already sound.
FAQ
Can you build a whole iOS app by vibe coding?
You can build most of the code by prompting an agent, but not the whole app. Shipping a paid iOS app also needs App Store Connect setup, signing and certificates, real-device testing, and App Review, all of which happen outside the agent's reach and stay your responsibility.
What can an AI agent actually do on an iOS project?
Inside the repository it is strong: writing SwiftUI views, building features and flows, refactoring, wiring modules together, and writing tests. On a project that builds from the command line, it can run a write-build-fix loop and check its own work.
What can't an AI agent do for an iOS app?
It cannot set up App Store Connect, handle signing and provisioning, see the running app to judge layout, guarantee App Review passes, or test real purchases on a device. Those depend on Apple's tools and your accounts, which the agent has no access to.
Why does my AI-written paywall show no products?
Almost always a product ID mismatch. The agent wrote the paywall code, but the product IDs have to match products created in App Store Connect and RevenueCat. The code can be perfect and still show nothing until the dashboards line up.
Is vibe coding good enough to ship a real app?
For the app's code, it can take you a long way, especially with clear conventions and a solid starting project. But treat it as a fast way to write the code, not a way to skip the App Store setup, testing, and review that shipping actually requires.
How do I get the most out of vibe coding on iOS?
Own the outside-the-repo setup up front, hand the agent a project that already builds, give it clear conventions so it stops guessing, and keep Xcode open to judge the running app. Let the agent write code and verify with builds; you handle config, design, and the store.
Spaceport does the parts the agent can't. It generates a production-ready SwiftUI Xcode project with the whole paid-app foundation wired up, onboarding, Apple and Google sign-in, RevenueCat subscriptions, Firebase analytics, an AI assistant, notifications, a home screen widget, and an Apple Watch app, and it sets up your subscription products and pricing in App Store Connect and RevenueCat through their APIs. Your agent then vibe-codes features on top of a real, buildable app instead of a blank project. From an indie iOS dev, for indie iOS devs.