Seeing no such module or unresolved import errors in Zed while editing Swift? These come from missing build context. Here is how to resolve them.
You are editing Swift in Zed and see red diagnostics like no such module or unresolved import for UIKit, SwiftUI, or a dependency.
Yet the same code may build fine in Xcode. This mismatch is confusing but has a clear explanation.
These errors come from the language server lacking the build context it needs to resolve modules.
SourceKit-LSP has to know how your code is built to find the right modules. When that context is missing, imports appear broken in the editor even if they compile elsewhere.
Swift modules are resolved using build settings, SDK paths, and generated artifacts. The editor does not guess these; it reads them from build information.
For Swift Package Manager packages, that information comes from Package.swift and a build. For iOS apps, it comes from Xcode's build products.
If you open a project without building it first, the language server has nothing to resolve against.
That is why imports of system frameworks or third-party packages show as missing until the correct build context exists.
The simplest fix is to generate build artifacts. For a package, run swift build in the project directory.
For an iOS app, build the target in Xcode at least once. This produces the module maps and products the server needs.
After building, reopen the Swift file in Zed and give the server a moment to re-index.
In many cases, the import errors clear as soon as the build context becomes available on disk.
If the missing module is a third-party dependency, make sure it has been fetched and built.
For Swift packages, run swift package resolve and then swift build so the dependency is compiled.
For Xcode projects using Swift Package Manager, let Xcode resolve packages, which downloads and builds them.
Until dependencies are resolved and built, the language server cannot see their modules and will flag the import.
System frameworks like UIKit and SwiftUI resolve most reliably when the correct SDK and build context are present.
App targets tie these to Xcode's build. That is why editing app code in isolation can surface import errors.
Where you can, move logic into local Swift packages. Package targets resolve modules more predictably in Zed.
This does not remove the need for Xcode. It simply gives the editor a cleaner context so imports stop showing as missing.
Confirm your Swift toolchain is set up by running swift --version and xcrun --find sourcekit-lsp.
Verify the active developer directory with xcode-select -p and correct it if it points to the wrong location.
A mismatched or missing SDK selection can make even standard imports look unresolved.
Once the toolchain and SDK are correct, rebuild so the language server picks up the proper module search paths.
After changing dependencies or build settings, the editor's index can lag behind reality.
Restart Zed to clear stale language server state, then reopen the project.
Run swift build again or rebuild in Xcode so the index reflects the current modules.
Give indexing time to complete before judging whether the import errors are gone. Large projects take a moment to settle.
Opening an isolated Swift file strips away the project context the language server uses to resolve imports.
Open the folder that contains Package.swift for a package, or the directory holding your app's sources and project files.
With the full project in view, SourceKit-LSP can read the structure it needs to map import statements to real modules.
This is one of the simplest fixes for no such module errors, and it is easy to overlook when you jump straight to a single file.
Big projects do not resolve every module instantly. Indexing takes time, and imports can look broken while it runs.
After building, give the language server a few moments before judging whether an import is truly unresolved.
Watch for the editor to settle. Diagnostics that appear right after opening often clear once indexing finishes.
If errors persist well after indexing should be done, then move on to checking the toolchain, dependencies, and build context.
Sometimes an import warning in Zed is purely a stale-context artifact, not a real problem with your code.
The reliable test is Xcode. If Xcode compiles the same file without complaint, the module genuinely resolves and the app is fine.
In that situation, trust the compiler over the editor's diagnostic and keep working, refreshing the index when convenient.
Treat editor diagnostics as helpful hints, but treat a successful Xcode build as the source of truth for whether code compiles.
Occasionally the import itself is simply wrong. A typo in a module name, or importing a product name that differs from the module, will always fail.
Check the exact module name your dependency exposes, since it does not always match the package name.
Correct the import to the precise module name, then let the editor re-resolve it.
This is worth a quick look before assuming the problem is build context, especially with third-party packages.
After large changes, the build products the language server reads can drift out of sync with your source.
A clean build regenerates module maps and artifacts from scratch, which often clears stubborn import errors.
For a package, remove stale build output and run swift build again. For an app, clean the build folder in Xcode and rebuild.
Once fresh artifacts exist on disk, reopen the file in Zed and let indexing catch up to the current state.
A clean rebuild is slower than an incremental one, but it is the most reliable way to rule out stale build products as the cause of phantom import errors.
To confirm the fix, open the file that showed errors and check that the import lines no longer show diagnostics.
Hover over a symbol from the previously missing module. Resolved hover info confirms the module is now found.
If the code builds in Xcode but Zed still complains, trust the Xcode build for compilation and treat the editor warning as a stale-context artifact.
And remember: resolving editor import errors does not change how you ship. Building, signing, and App Store submission remain Xcode and Apple Developer Program tasks.
The language server lacks build context. Xcode has the SDK paths and build products; the editor needs those too. Build the project first so the server can resolve modules.
Resolve and build dependencies with swift package resolve and swift build, or let Xcode resolve packages, so the module exists on disk.
They can, when the correct SDK and build context are present. Building the app in Xcode first usually makes those imports resolve.
Trust Xcode for compilation. If Xcode builds and Zed still flags an import, it is likely a stale editor context, not a real error.
No. It only cleans up editor diagnostics. Building, signing, and App Store submission still require Xcode and the Apple Developer Program.