When Swift code completion stops working in VS Code with SweetPad, the cause is almost always SourceKit-LSP failing to index — usually a missing or stale buildServer.json. Here is how to get it back.
You open a Swift file in VS Code with SweetPad and the editor feels dumb: no autocomplete when you type a member access, no quick info on hover, jump-to-definition does nothing, and imported frameworks like SwiftUI or UIKit are underlined as unknown even though the project builds perfectly in Xcode. Sometimes completion worked yesterday and broke after you changed the project. The crucial framing is that Swift completion in VS Code comes from SourceKit-LSP, and SourceKit-LSP can only complete what it has indexed. For an Xcode project, it learns how to index each file from buildServer.json, which is produced by xcode-build-server. So missing completion is almost never a problem with your code — it is a broken link somewhere in the SourceKit-LSP indexing chain. The fixes below address that chain in order of likelihood, beginning with the most common cause, a missing or stale buildServer.json, and moving toward rarer toolchain and configuration issues. Because your code compiles, you can be confident the fix is about indexing, not correctness.
The most common and highest-yield fix is regenerating buildServer.json. This file tells SourceKit-LSP how to obtain compiler arguments for your Swift files, and if it is missing, stale, or was generated against a different scheme or an older project layout, completion breaks. Open the Command Palette, run SweetPad's build-server configuration command, and select the scheme that builds the target you are editing. If a file already exists but completion is broken, delete buildServer.json first, then regenerate it fresh, since a corrupted or outdated file can be worse than none. Confirm the regenerated file sits at the actual project root that VS Code has open, not in a subfolder, because SourceKit-LSP looks for it relative to the workspace root. After regenerating, reload the VS Code window or restart the language server so it picks up the new configuration. This one step resolves the large majority of missing-completion cases, especially those that appear right after changing schemes, adding targets, or regenerating the project.
SourceKit-LSP often needs artifacts from a real build to resolve modules and generated code, so if completion is partial — your own symbols work but imported frameworks or dependencies do not — the project probably has not been built with the current configuration. Run a build through SweetPad or in Xcode, wait for it to finish successfully, then give the language server time to index in the background. On large projects the first indexing pass can take several minutes, so do not conclude it failed until you have waited. This step is especially important right after adding a Swift Package Manager dependency, running pod install, or regenerating the project with Tuist or XcodeGen, because those modules only exist after a build. If the project will not build, fix the build first; SourceKit-LSP cannot index against outputs and compiler arguments that were never produced. A successful build followed by a patient indexing pause fills in the gaps that a fresh buildServer.json alone sometimes leaves.
Language servers can wedge, especially after the project changes underneath them, and a stuck SourceKit-LSP will keep serving stale or empty results until it is restarted. In VS Code, reload the window from the Command Palette, or restart the Swift language server if a command is available for it. This forces SourceKit-LSP to re-read buildServer.json and re-index from a clean state. It is the natural companion to regenerating configuration: after you produce a new buildServer.json, the running server may still be using the old one until it restarts. If you frequently switch branches or regenerate the project, get in the habit of reloading the window afterward. A restart is cheap and non-destructive, and it resolves a surprising number of cases where the configuration is actually correct but the live server never picked up the change. If completion returns after a restart, the underlying files were fine and the server had simply gone stale, which is useful diagnostic information for next time.
If regenerating buildServer.json does nothing because the generation itself fails, the underlying tool may be missing. Open a terminal and run xcode-build-server --help. If it is not found, install it with brew install xcode-build-server, then regenerate the configuration. If it is installed but SweetPad cannot invoke it, suspect a PATH mismatch: VS Code launched from the Dock may not inherit your shell's PATH, so Homebrew's binary directory is invisible to the extension. Check the location with which xcode-build-server and make sure that directory is on the PATH VS Code uses, or launch VS Code from the terminal so it inherits your environment, then restart it. Without a working xcode-build-server, no valid buildServer.json can be produced for an Xcode project, and SourceKit-LSP will never get the compiler arguments it needs. This cause is less common than a stale configuration file, but when generation silently fails, an uninstalled or unreachable xcode-build-server is the usual explanation.
When the standard fixes do not restore completion, the logs tell you exactly where the chain breaks. In VS Code, open the output panel and select the SourceKit-LSP channel. The logs reveal whether the server started, whether it found and read buildServer.json, which files it indexed, and any errors fetching compiler arguments. A message about a missing build server or a failure to run xcode-build-server points at the installation and configuration fixes above. Errors about a missing SDK, an invalid developer directory, or an unusable toolchain point instead at your Xcode installation. Log lines about specific files failing to index can reveal a scheme mismatch, where the file you are editing is not part of the scheme buildServer.json was generated for. Reading these logs converts trial-and-error into targeted diagnosis. Because SourceKit-LSP and xcode-build-server are open, widely used tools, their error messages are searchable and well understood, so matching a log line to a cause is far faster than blindly regenerating configuration repeatedly.
Rule out the foundation, since SourceKit-LSP itself comes from the Xcode toolchain. Run xcrun --find sourcekit-lsp and confirm it returns a path; if it does not, your toolchain is not correctly set up. Run xcode-select -p and ensure it points inside your full Xcode app rather than the standalone Command Line Tools, fixing it with sudo xcode-select -s and your Xcode path if needed. Make sure you launched Xcode at least once to finish component installation and accepted the license. If you recently updated macOS or Xcode, verify the update fully completed, because a half-installed toolchain can leave SourceKit-LSP unable to index until it finishes. Using the SourceKit-LSP that ships with your Xcode toolchain — rather than a mismatched third-party language server — keeps completion consistent with the compiler that actually builds your app. These foundational checks are last because they are the least frequent cause, but when nothing else explains the failure, a misconfigured or incomplete Xcode toolchain is often the hidden reason completion never works.
Occasionally the problem is not the indexing chain at all but a conflict inside VS Code itself, so it is worth ruling that out before spending more time on buildServer.json. If you have more than one Swift language extension installed, they can both try to launch a language server and interfere with each other; keep the single Swift/SourceKit-LSP integration your workflow relies on and disable duplicates. Check that the file you are editing is actually inside the workspace folder VS Code has open — a Swift file opened standalone, outside the project root, will not be indexed because the server resolves buildServer.json relative to that root. Confirm the file's language mode is set to Swift in the status bar, since a misdetected language disables Swift completion entirely. Finally, make sure no aggressive settings are suppressing suggestions, such as a disabled quick-suggestions option for the editor. These editor-level issues are less common than a stale configuration, but they explain the frustrating cases where the whole toolchain checks out and completion still refuses to appear.
Completion comes from SourceKit-LSP indexing, not from the compiler. If the code builds but completion is missing, the indexing chain is broken — usually a missing or stale buildServer.json — not your code. Regenerating that file is the most common fix.
Run SweetPad's build-server configuration command from the Command Palette and select the scheme that builds your target, or run xcode-build-server config manually. If a stale file exists, delete it first, regenerate, then reload the VS Code window so the server re-reads it.
Those modules likely have not been built with the current configuration, so SourceKit-LSP cannot resolve their symbols. Build the project, wait for indexing to finish, and regenerate buildServer.json if you recently added the dependency.
Usually the project changed but buildServer.json did not — a new scheme, added target, branch switch, or project regeneration. Regenerate the configuration and reload the window. A wedged language server that never picked up the change is another common cause a restart fixes.
Reload the VS Code window from the Command Palette, or use a restart-language-server command if available. This forces SourceKit-LSP to re-read buildServer.json and re-index from a clean state, which resolves stale-server cases.
Open the output panel in VS Code and select the SourceKit-LSP channel. The logs show whether the server started, found buildServer.json, indexed your files, or hit errors about a missing build server, SDK, or toolchain, pointing you to the exact cause.