I Wrote Swift in Cursor for a Week. Xcode, We Need to Talk.

Last Tuesday, I was on a Swift.org rabbit hole at 1 AM — the kind where you click one link and suddenly it’s two hours later and your tea is cold and your cat is judging you. That’s when I found a blog post that made me sit up straight.

The official Swift extension had hit the Open VSX Registry. Full LSP. Full debugging. Full test explorer. In Cursor. In Amazon’s Kiro. In every AI IDE that isn’t Xcode.

I stared at my monitor the way you stare at a text from an ex saying “I’ve changed.” Part excitement. Part suspicion. Part okay but I’ve been hurt before.

So I did what any rational person would do. I closed Xcode for a week.

The Quiet Announcement That Changes Everything

On April 8, Tracy Miranda from the Swift Build and Packaging Workgroup published a post on Swift.org titled “Expanding Swift’s IDE Support.” It read like a polite breakup letter to Xcode’s 16-year IDE monopoly.

The Swift extension landed on the Open VSX Registry — the vendor-neutral extension marketplace run by the Eclipse Foundation. AWS, Google, and Cursor are initial customers. Any editor that speaks VS Code extensions can now install Swift support with one click.

What you get:

Code completion and go to definition via SourceKit-LSP
Refactoring and quick fixes
Full debugging via LLDB DAP
DocC documentation support
Test explorer for both XCTest and Swift Testing

And here’s the kicker that really matters: agentic IDEs like Cursor can now automatically install Swift. No manual download. No dragging toolchains around like it’s 2012. You open Cursor, search “Swift” in Extensions, and the bird lands on your shoulder.

Apple even published an official Cursor setup guide on Swift.org. Read that again. Apple published a Cursor setup guide. On their own website. If that doesn’t tell you where this is heading, I don’t know what does.

Setting Up: 15 Minutes to Freedom

I installed the Swift extension, grabbed Sweetpad (the VS Code extension that wraps xcodebuild commands into something a non-Xcode editor can work with), and opened one of my real projects — the PromptKit codebase. A production SwiftUI app with networking, SwiftData, and the usual tangle of view models. Not a tutorial counter app.

The first build took a while. Expected. Sweetpad needs that initial swift build to populate the SourceKit index. After that? Jump to definition worked. Find all references worked. Code completion was snappy.

And then I hit Cmd+L to open Cursor’s AI chat.

That’s when things got interesting.

Where Cursor Destroyed Xcode

The AI. Obviously. But it’s not just “autocomplete is nice.” It’s the depth of context.

Cursor’s agent mode understood my Swift code structure. I highlighted a view model, asked “why is this publisher not firing on the second subscription?” and got an answer that referenced my actual Combine pipeline. My types. My bug. Not a generic Stack Overflow paste from 2019.

I refactored a SwiftUI navigation stack across three files by describing what I wanted in plain English. Cursor made the changes, I reviewed the diff, hit accept. Three files. Zero typos. Zero missing imports. The whole thing took maybe 90 seconds — a task that would have been 15 minutes of careful manual editing.

We’ve compared AI coding tools before, and the pattern holds: when an IDE natively understands your project structure and has AI that can reason about it, the productivity gap becomes absurd.

Thomas Ricouard — the developer behind IceCubesApp, one of the most popular open-source SwiftUI apps — switched to Cursor for his iOS workflow and described it as the kind of upgrade you don’t come back from.

Meanwhile, Xcode’s AI assistant gives me suggestions that are sometimes helpful and sometimes feel like they were written by someone who read about Swift but never shipped an app. We covered this in our honest three-month review of Xcode’s AI agents — it’s gotten better, but “better than bad” and “actually good” are different postcodes.

Where Xcode Still Wins (And It’s Not Close)

Before you yeet Xcode into the trash, let me save you some pain. There are things Cursor simply cannot do.

Simulators. Cursor can’t launch one. You need Xcode installed anyway for the simulator runtime, and running on a device requires Xcode’s code signing pipeline. This is the moat Apple dug, and it’s deep enough to park a submarine in.

Instruments. You’re not profiling memory leaks in Cursor. You’re not running Time Profiler or checking for hangs. Xcode’s performance tools are its crown jewels, and nothing in the VS Code universe comes close. If you’re doing the kind of optimization work we cover in our SwiftUI at Scale course, Instruments is non-negotiable.

SwiftUI Preview Canvas. If you use live previews (and you should), Cursor doesn’t have them. You get a text editor. A very smart text editor. But no hot-reloading visual feedback while you tweak padding values.

Interface Builder, Asset Catalogs, Core Data Model Editor. All Xcode-only. If your project touches any of these, you’re opening Xcode whether you like it or not.

Think of it like this: Cursor is the friend who’s amazing at conversation, always has great recommendations, and makes everything more fun. Xcode is the friend with a pickup truck. Less exciting, but when you need to move a couch, there’s no substitute.

My Actual Workflow After Seven Days

Here’s what actually happened: I didn’t replace Xcode. I supplemented it.

The workflow that emerged surprised me:

Heavy refactoring? Cursor. The AI-assisted multi-file edits are a genuine superpower.
Writing new SwiftUI views? Cursor, with the AI suggesting layout patterns from my existing design system.
Debugging a crash? Xcode. The breakpoint UI and console just work better.
Running on my iPhone? Xcode. No choice.
Performance profiling? Xcode. Still the only game in town.
Writing Swift packages or server-side Swift? Cursor, exclusively. No Xcode needed at all.

It’s not either/or. It’s “which tool is better for this specific task right now.”

And honestly? That’s exactly how it should be. We’ve been Stockholm-syndromed into thinking one IDE must do everything. Web developers figured this out a decade ago — they use VS Code for writing, browser DevTools for debugging, and whatever terminal they prefer for builds. They don’t expect one ring to rule them all. We shouldn’t either.

What This Means Two Weeks Before WWDC

Apple publishing an official Cursor setup guide on Swift.org is the most understated power move of 2026. They’re telling you, in diplomatic Apple fashion: Swift is bigger than Xcode.

WWDC is June 8. Two weeks away. My prediction: Apple will double down on this direction. Swift on more platforms — it already runs on Android. Better LSP tooling. Maybe an improved debugging protocol that doesn’t chain you to Xcode. Apple wants Swift everywhere, and “everywhere” includes AI IDEs where developers increasingly live.

Swift 6.2 already made concurrency more approachable. The IDE expansion makes the development experience more approachable. See the pattern? Apple is systematically removing every reason not to write Swift.

The developers who set up Cursor + Swift this month will have a head start when WWDC drops whatever’s next. The ones who wait will be six weeks behind.

Try It This Weekend

Here’s the actual setup — it takes about 15 minutes:

Install Cursor (or Kiro, or VSCodium — any Open VSX-compatible editor)
Open Extensions (⇧⌘X), search “Swift”, install
Install the Sweetpad extension for xcodebuild integration
Open your project and build once (swift build) to populate the index
Start refactoring with an AI that actually understands your code

The Swift.org Cursor setup guide walks you through every detail, including configuring custom AI skills for Swift-specific suggestions.

If you’re learning SwiftUI from scratch, start with our SwiftUI Foundations course and bring Cursor along for the ride — the AI chat is like having a tutor sitting next to you while you work through the lessons. If you’re building production apps, the SwiftUI at Scale course covers modular SPM packages, composition roots, and protocol-based networking — exactly the kind of clean architecture that AI tools understand best.

Xcode isn’t going anywhere. But it’s no longer the only chair at the table.

And honestly? Competition is the best thing that could happen to it.