A step-by-step guide to configuring Zed for Swift using SourceKit-LSP, so you get completions, diagnostics, and navigation while keeping Xcode for builds.
Zed is a fast, open-source editor, and it talks to language servers through the Language Server Protocol. For Swift, that language server is SourceKit-LSP, maintained by Apple as part of the Swift toolchain.
With SourceKit-LSP connected, Zed can offer code completion, diagnostics, hover information, and go-to-definition for your Swift code.
This setup does not turn Zed into Xcode. You will still build, run in the Simulator, sign, and submit through Xcode and the Apple Developer Program.
The goal here is a fast editing surface for Swift that complements Xcode. This works best on Swift Package Manager packages, where module and dependency resolution is straightforward.
First, make sure you are on a Mac with Xcode or at least the Xcode Command Line Tools installed. SourceKit-LSP ships with the Swift toolchain that comes with Xcode.
Install Xcode from the Mac App Store, or install command line tools by running xcode-select --install in Terminal.
Confirm Swift is available by running swift --version in your terminal. You should see a version string print without errors.
Also confirm the language server binary is reachable by running xcrun --find sourcekit-lsp. If that prints a path, your toolchain exposes SourceKit-LSP, which is what Zed needs.
Download Zed from its official site and install it like any Mac application. Launch it once to make sure it opens cleanly.
Open your Swift project folder in Zed using File, Open, or by running the zed command in a directory if you installed the CLI helper.
For the smoothest first experience, start with a Swift Package Manager package that contains a Package.swift manifest. Package-based projects resolve modules cleanly for the language server.
If you are working inside a full iOS app, open the folder containing your Swift sources. Just be aware that app targets often need Xcode-generated build products for full indexing.
Zed uses extensions and language configuration to wire up language servers. Open Zed's extensions panel and look for the Swift extension, then install it.
The Swift extension is what associates .swift files with SourceKit-LSP so Zed knows which server to launch.
After installing, reopen a Swift file. Zed should attempt to start the language server automatically in the background.
Give it a moment on first launch. The server needs time to scan your package and build its index before completions become accurate.
Open a Swift source file and place your cursor inside a function body. Start typing a known symbol and wait for the completion popup to appear.
Hover over a type or function name. If SourceKit-LSP is running, you should see hover documentation or type information.
Try go-to-definition on a symbol. Jumping to the declaration confirms the server has indexed your code.
If nothing appears, open Zed's log or language server output to see whether the server started. A missing or crashed server is the most common reason completions do not show up.
For Swift packages, SourceKit-LSP usually finds what it needs from Package.swift. Run swift build once in the terminal so build artifacts exist and indexing improves.
For iOS app targets, the language server benefits from build products that Xcode generates. Build the app in Xcode first so those artifacts are present on disk.
Keep your terminal handy. Running swift build or letting Xcode build once often resolves missing-module and unresolved-symbol noise in the editor.
Remember that some UIKit and SwiftUI symbols resolve best when the correct SDK and build context are available, which is another reason the package workflow is the simplest starting point.
Decide clearly which tool does what. Use Zed for writing, refactoring, searching, and AI-assisted edits, and use Xcode to build, run, debug, and profile.
Keep both open on the same project. When you save in Zed, Xcode picks up the changes on disk, and vice versa.
Use Xcode whenever you need the Simulator, SwiftUI previews, Instruments, signing, or archive and upload. These have no equivalent inside Zed.
This split gives you Zed's speed for authoring and Xcode's full native toolchain for delivery. It is the most reliable way to use Zed on Apple platforms today.
Zed stores its configuration in a JSON settings file you can open from the command palette. Most Swift users do not need to change much, but a few tweaks help the editor match how you work.
You can adjust tab size, formatting behavior, and how eagerly completions appear so the editor fits your Swift style rather than fighting it.
If you keep more than one Swift toolchain around, remember that Zed relies on the toolchain that xcrun resolves. Keeping your command line tools selection correct is what points the language server at the right SourceKit-LSP.
Start with the defaults and change settings only when you have a concrete reason. Fewer custom settings means fewer moving parts to debug later.
A frequent mistake is opening a single Swift file instead of the whole project folder. The language server needs project context to resolve modules, so always open the containing directory rather than a lone file.
Another is expecting full app-target intelligence before Xcode has built the app even once. Build first, then give Zed a moment to index against the resulting products.
Do not assume a missing completion means broken code. It often means the index is still building or the build context is not present yet, especially right after opening a project.
Finally, keep Xcode and its command line tools updated. A mismatched or outdated toolchain is a common source of subtle language server problems that are easy to overlook.
Do a quick end-to-end check. Edit a Swift file in Zed, save it, switch to Xcode, and build to confirm your change compiles.
If completions stop working after a dependency change, run swift build again or rebuild in Xcode so the index refreshes.
If the server will not start, verify xcrun --find sourcekit-lsp still returns a path and that Xcode command line tools are selected with xcode-select -p.
When in doubt, restart Zed and reopen the project. A clean restart clears stale language server state and is often the fastest fix.
Yes. SourceKit-LSP and the Swift toolchain come with Xcode or the Xcode Command Line Tools, and you still need Xcode to build and ship iOS apps.
App targets often need Xcode-generated build products for full indexing. Build the app in Xcode first, then the language server can resolve more symbols.
Run xcrun --find sourcekit-lsp in Terminal. If it prints a path, your toolchain exposes the language server that Zed needs.
No. Zed edits code; use Xcode to build, run in the Simulator, sign, and submit to the App Store.
Restart Zed, confirm your command line tools path with xcode-select -p, and run swift build to refresh the index.