Cursor handles Swift / SwiftUI better than the terminal-first agents because most iOS work involves visual layout and the codegen needs to see selection state. Xcode does what only Xcode can: simulators, signing, profiling, App Store Connect. Claude (chat) is where you decide what to build before either tool starts editing.
Before you open Xcode, decide what you're building. Claude is the chat surface for the design/info-architecture/data-model conversation. Especially valuable on iOS where over-scoping is costly (every screen needs design polish to look native).
Inline AI completions for Swift, Composer for multi-file changes, and decent SwiftUI preview integration. Cursor's hold on Swift code quality has improved a lot — better than copy-pasting into a chat tab, comparable to Claude Code for typical iOS work.
Where the app actually compiles and runs. Required for Simulator, Instruments (profiling), Signing & Capabilities, and App Store Connect distribution. AI agents drive Cursor; you drive Xcode.
Projects maintain context over months of work, with a coordinator agent that plans work and delegates to subagents running in parallel. Projects can watch Slack channels or run on schedules to take action without being prompted, keeping shared context across all agents involved.
Projects is a new feature that maintains context over months of work and delegates tasks to thousands of subagents. A coordinator agent plans the work and delegates to implementation agents that run in parallel. Projects can watch Slack channels, follow PRs, or run on a schedule to take action automatically without prompting.
Projects enables managing feature development, migrations, and full apps with a coordinator agent that plans work, delegates to subagents, and maintains context over months. The coordinator runs agents in parallel and can watch Slack channels or run on schedules to automatically pick up work without explicit prompting.
Cursor now supports running cloud agents on self-hosted infrastructure including AWS Lambda, Coder, Cloudflare, and others, keeping your code and secrets on internal machines. The platform includes dynamic pool scheduling for teams and computer use on Linux and Mac through self-hosted workers.
Before any code: scope the screens, the data model, the privacy story (everything Apple cares about during review).
Plan a small, well-scoped iOS app for the idea below. Don't write Swift code yet.
Idea:
"""
{{1-line product description}}
"""
Constraints:
- Solo developer, weekend MVP, then iterate.
- Native iOS only (SwiftUI). No cross-platform unless I push back.
- Local-only data unless I ask for sync (privacy + review speed).
- No 3rd-party SDKs that block App Store review (no obscure analytics, no SDKs that violate ATT).
Output, in this order:
1. **Screens** (3 to 6 max for MVP) — name + 1-line purpose.
2. **Data model** — Swift types or SwiftData / Core Data schema, whichever is simpler.
3. **Permissions / capabilities** — exactly what entitlements you need and the App Store review reasons.
4. **App Store hooks** — name candidates (3), category, the 1-line subtitle, the "what's the screenshot story".
5. **Out of scope for v1** — 3 to 5 features I should NOT build before launch.
Push back if the idea has obvious App Store rejection risks.Open Cursor at the project root. Use Composer (agent mode) to scaffold the screens from step 1. Don't accept the whole diff at once — go screen-by-screen so SwiftUI previews stay healthy.
Build a SwiftUI screen for {{screen_name}} from the plan we agreed on.
Constraints:
- SwiftUI only. No UIKit unless I explicitly ask.
- Use the {{e.g. SwiftData / Core Data / @Observable}} pattern already in this project.
- Match the existing folder structure (look at @Views and @Models before adding files).
- No new dependencies. No SwiftPM additions in this turn.
- Add a #Preview at the bottom that runs without any external state.
Output: the new file(s) with a 2-line summary of what was added, ready for me to accept hunk-by-hunk.Cmd-R in Xcode. Cursor's preview is fast; Xcode's Simulator is the truth. If the layout breaks at smaller sizes (SE) or with Dynamic Type at the largest setting, fix before moving on — App Review reads accessibility.
Xcode → Product → Archive → Distribute App → App Store Connect. Once: set up automatic signing in Signing & Capabilities. TestFlight build is ready in ~10 min.
Use Claude to draft the App Store description, the privacy nutrition label answers, and the review-notes message. App Store rejections are usually metadata or privacy issues, not code.
Both apps built solo. Cursor handled ~80% of the SwiftUI; the dev wrote Xcode signing config + the privacy label by hand. Both apps cleared App Review on the first submission, mostly because the privacy story was scoped tight from the Claude planning step.
Cursor's first instinct is occasionally to drop into UIKit for things SwiftUI can do natively. Reject and re-prompt; mixing UIKit and SwiftUI early adds 2x the maintenance cost.
Apple rejects more apps for privacy-label mismatches than for actual bugs. Use Claude to walk through every framework you import and what data it touches — get the answers right before submitting.
Some terminal-only devs try to build with `xcodebuild` and skip Xcode. You can — but you'll fight signing, capabilities, and App Store Connect issues that the GUI surfaces clearly. Use Xcode for the deploy lane even if your editor is Cursor.
What changed in AI tools and the stacks that ship. One email a week.