A step-by-step guide to configuring Windsurf for Swift work: installing the editor, wiring up SourceKit-LSP for code intelligence, and pairing it with Xcode so you can edit with AI and still build and ship natively.
This guide assumes you are on a Mac, because Apple's toolchain is Mac-only. You will need macOS, Xcode installed from the App Store, and the Command Line Tools.
Windsurf is the editor you will write in, and Xcode remains the tool that compiles, signs, and runs your app.
The goal of this setup is a clean two-tool loop: edit with AI in Windsurf, build and run in Xcode. Get that mental model straight before you start and the rest is easy.
Have a real Swift project ready to test with. A Swift Package Manager package is the smoothest case for language-server features.
Download Windsurf from its official site and install it like any Mac application. Because it is built on the VS Code lineage, the first launch will feel familiar.
Note that the product has changed hands and branding over time; it is now part of Cognition. The download and account flow may carry that branding, but the editor and the Cascade agent are the same tool this guide describes.
Sign in or create an account to enable the AI features, including the Cascade agent. The free tier is enough to complete this entire setup.
Open your project folder with File, Open Folder, pointing at the root of your Swift package or app repository.
Take a moment to set your theme and keybindings. If you are coming from VS Code, you can often import or reuse your familiar configuration.
Even though you will edit in Windsurf, Xcode is mandatory. Install it from the Mac App Store if you have not already.
Then install the Command Line Tools by running `xcode-select --install` in Terminal. These provide `xcodebuild`, `swift`, and the underlying toolchain that both Xcode and your language server rely on.
Confirm the toolchain is active by running `xcode-select -p` and `swift --version`. You should see a valid developer directory and a Swift version.
This step is what makes command-line builds and SourceKit-LSP work. Do not skip it.
SourceKit-LSP is Apple's official Swift language server, and it is what gives Windsurf real completion, diagnostics, and go-to-definition for Swift.
Install a Swift language extension from the Windsurf/VS Code extension marketplace. The official Swift extension is the most reliable choice and helps locate SourceKit-LSP for you.
SourceKit-LSP ships with the Swift toolchain you installed via Xcode, so in most cases the extension finds it automatically. If needed, point the extension at the toolchain path shown by `xcrun --find sourcekit-lsp`.
Reload the window after installing. Open a Swift file and confirm you see syntax-aware completion and inline diagnostics.
SourceKit-LSP works best when it understands how your code builds. For Swift Package Manager projects, opening the folder containing `Package.swift` is ideal.
For an `.xcodeproj` or `.xcworkspace` app, intelligence can be less complete because Xcode-specific build settings are not fully visible to the language server. Expect strong support for your Swift sources and weaker coverage for Xcode-only constructs.
Let the language server index. The first index pass can take a little time on large projects, after which navigation and completion become responsive.
If completion looks empty, try building once from the command line so the language server has fresh build artifacts to reason about.
Windsurf includes a terminal, and you can drive Xcode's build system from it without leaving the editor.
For a package, `swift build` and `swift test` work directly. For an app, use `xcodebuild` with your scheme, for example `xcodebuild -scheme YourApp -destination 'platform=iOS Simulator,name=iPhone' build`, choosing a simulator name that exists on your machine.
Keeping builds in the integrated terminal tightens your loop: you edit, you build in the same window, and you read compiler errors right next to your code.
Remember that running the app on the Simulator and debugging visually is still smoother in Xcode itself. Use the terminal for quick compile checks, Xcode for full run-and-debug.
Open the Cascade panel and point it at a small, low-risk task first, like adding a computed property or writing a unit test.
Review every diff before accepting. Cascade can edit multiple files at once, which is powerful but means you must read what it changed.
Decide your policy on command execution. Cascade can run terminal commands; keep that on a short leash early on, approving each command until you trust the flow.
Good guardrails make the agent a force multiplier rather than a source of surprise edits.
Now combine everything into a daily rhythm. Write and refactor Swift in Windsurf, leaning on Cascade for multi-file changes and on SourceKit-LSP for accuracy.
When you are ready to verify, build in Xcode or via `xcodebuild`. Always compile before trusting AI-generated Swift, since suggestions can reference outdated or nonexistent APIs.
Use Xcode for the things only it can do: Simulator runs, Interface Builder, asset catalogs, signing, archiving, and App Store Connect uploads. Shipping also requires an Apple Developer Program membership.
This loop gives you AI-assisted authoring with the safety of Apple's real toolchain underneath. That is the whole point of the setup.
With the core Swift path working, spend a few minutes on the extensions that make daily work smoother. Git tooling, a good diff view, and a linter or formatter such as SwiftFormat or SwiftLint all run happily in a VS Code-style editor.
Because Windsurf shares the VS Code extension model, most general-purpose extensions you already rely on will install and behave as expected. Avoid stacking several Swift language extensions at once, though, since competing language-server clients can fight over the same files.
Set up your workspace settings per project rather than globally where it matters, so a package with strict formatting rules does not leak its config into unrelated repositories.
A small amount of configuration here pays back every day, because it keeps the editor consistent with whatever your team already enforces in review and CI.
Windsurf is a cloud-assisted tool, which means prompts and code context can be sent to a model to produce suggestions. For a personal project that is rarely a concern, but for proprietary or regulated codebases it deserves a deliberate decision.
Before wiring the agent into a work repository, read the current data-handling and retention terms on the official site, and check whether your organization has a policy on AI coding assistants.
Many teams resolve this by scoping where the agent is allowed, keeping secrets out of the workspace, and relying on environment variables rather than committed credentials. None of that is specific to iOS, but it matters as much here as anywhere.
Getting this right once, at setup time, avoids an awkward conversation later and keeps the productivity benefits without the compliance surprise.
Yes, absolutely. Windsurf edits code but cannot compile, run the Simulator, sign, or submit apps. Xcode and a Mac remain required for building and shipping any iOS app.
Through SourceKit-LSP, Apple's official Swift language server, usually via the Swift extension from the marketplace. It provides completion, diagnostics, and navigation, working best on Swift Package Manager projects.
You can run swift build, swift test, or xcodebuild from the integrated terminal for quick compile checks. For full run-and-debug on the Simulator, Xcode is still the better tool.
You can run Windsurf there, but iOS development requires Apple's Mac-only toolchain. Without macOS and Xcode you cannot compile or ship an iOS app, regardless of the editor.