Troubleshoot SweetPad when the build server fails — from a missing buildServer.json and an uninstalled xcode-build-server to the wrong scheme — with concrete checks in order of likelihood.
The typical symptom is that SweetPad opens your Swift files but the intelligence layer is dead: no code completion, no jump-to-definition, red squiggles under valid imports like SwiftUI or UIKit, or errors claiming symbols cannot be found even though the project compiles fine in Xcode. Sometimes SweetPad's build-server command appears to do nothing, or you see log messages mentioning a missing build server or a failure to read compiler arguments. The important insight is that these are not compiler errors — your code is fine. They are indexing errors, meaning SourceKit-LSP does not have the information it needs to understand your project. That information flows through xcode-build-server and the buildServer.json file it produces. So when the build server is not working, the fix is almost always about that chain: is the tool installed, did it generate a valid configuration file, and does that file reflect the correct scheme and current project structure. The following checks address these causes in order of how often they are the culprit.
The most common cause is that xcode-build-server is simply not installed, or is installed but not visible on the PATH that SweetPad and VS Code use. Open a terminal and run xcode-build-server --help. If you get a command-not-found error, install it with Homebrew using brew install xcode-build-server. If it is installed but SweetPad still cannot find it, the problem is usually PATH: VS Code launched from the Dock may not inherit the same PATH as your shell, so Homebrew's binary directory might be missing. Confirm where the tool lives with which xcode-build-server, and ensure that directory is on your PATH. Restarting VS Code after installing, or launching it from the terminal so it inherits your shell environment, frequently resolves this. Do not overlook this step just because the tool works in your terminal — SweetPad runs it from within VS Code's environment, and a PATH mismatch between the two is one of the most frequent reasons the build server appears broken.
If the tool is installed, the next suspect is the buildServer.json file. Look at your project root for a file named buildServer.json. If it is absent, SourceKit-LSP has no map for your Xcode project and completion will not work. Generate it by running SweetPad's build-server configuration command from the Command Palette and selecting your scheme, or run xcode-build-server config manually against your workspace or project and scheme. If the file exists but completion is still broken, it may be stale or invalid — for instance, it might reference an old scheme, point at build paths that no longer exist, or have been generated against a project that has since changed. When in doubt, delete it and regenerate a fresh one. Also confirm the file is 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. A present, valid, current buildServer.json is the single most important ingredient for a working build server.
buildServer.json is generated against a specific scheme, and choosing the wrong one is a subtle but common cause of partial or missing completion. If you generated the configuration against a framework scheme, a test scheme, or a scheme whose build graph does not include the files you are editing, SourceKit-LSP will lack compiler arguments for those files and completion will fail selectively. Regenerate buildServer.json against the scheme that actually builds the app target you are working on. If your repository has multiple apps or many schemes, make sure the selected scheme's build includes the module you are editing. Another related pitfall is a scheme that is not shared: if the scheme you expect does not even appear in SweetPad's list, open Xcode's scheme management, mark it as shared, and it will become selectable. After changing the scheme, always regenerate the build-server configuration, because the old file still describes the previous scheme's build graph and will keep producing wrong or missing results until you refresh it.
SourceKit-LSP frequently needs artifacts from a real build to resolve modules, generated code, and dependencies. If you generated buildServer.json but never actually built the project, completion for imported frameworks and package dependencies may be missing because those modules have not been compiled yet. Run a build through SweetPad or in Xcode, wait for it to finish successfully, then give SourceKit-LSP time to index. This is especially important right after adding a Swift Package Manager dependency, running pod install, or generating the project with Tuist or XcodeGen, because the new or regenerated modules only exist after a build. If the project fails to build, fix the build first — no build-server configuration can compensate for a project that does not compile, since the compiler arguments and module outputs it depends on will not be produced. A clean, successful build followed by a short indexing pause resolves a large share of cases where the configuration looks correct but symbols still fail to resolve.
When the obvious checks do not fix it, the logs usually reveal the real cause. In VS Code, open the output panel and select the SourceKit-LSP channel to see what the language server is doing. The logs typically show whether it started at all, whether it located buildServer.json, which files it indexed, and any errors reading compiler arguments. Messages about a missing build server, a failure to launch xcode-build-server, or an inability to find a scheme point directly at the earlier checks. Errors about missing SDKs or an invalid developer directory point instead at your Xcode installation — confirm xcode-select -p returns a valid Xcode path and that you have launched Xcode at least once to finish component installation. Reading these logs turns guesswork into diagnosis. Because every component here is standard, open tooling, the error messages are searchable and well understood, and matching the exact log line to a cause is far faster than repeatedly regenerating configuration and hoping the problem disappears.
Rule out the foundation. SweetPad and xcode-build-server both assume a healthy, correctly selected Xcode toolchain. Run xcode-select -p and confirm it points inside your Xcode application rather than at the standalone Command Line Tools; if it is wrong, fix it with sudo xcode-select -s pointing at your Xcode app. Make sure you have opened Xcode at least once so it finished installing components and you accepted the license, which you can also accept with sudo xcodebuild -license. Confirm xcrun --find sourcekit-lsp returns a path, proving the language server exists in the toolchain. If you recently updated macOS or Xcode, a mismatched or half-installed toolchain can break indexing until the update completes. These foundational issues are less common than a missing buildServer.json, which is why they are here, but they are worth checking when nothing else explains the failure. A correctly selected, fully installed Xcode is the bedrock the entire SweetPad build-server chain stands on.
Even with every file correct, a running SourceKit-LSP instance can hold onto stale state, so a restart is often the step that finally makes a freshly regenerated buildServer.json take effect. After you install xcode-build-server, regenerate the configuration, or change schemes, reload the VS Code window from the Command Palette, or use a restart-language-server command if one is available. This forces SourceKit-LSP to re-read buildServer.json and re-index from a clean starting point rather than continuing with the arguments it loaded when the project first opened. The pattern to internalize is regenerate-then-restart: producing a new configuration file does not retroactively update a server that has already started. If completion springs back to life immediately after a reload, you have learned that your configuration was actually correct and only the live server was stale, which is valuable for diagnosing the next occurrence quickly. Reloading is cheap and non-destructive, so make it a reflex after any change to the build-server configuration or the toolchain, before assuming a deeper problem exists.
Because those are indexing errors from SourceKit-LSP, not compiler errors. They mean the language server lacks the compiler arguments for your files, usually due to a missing or stale buildServer.json or an uninstalled xcode-build-server, not a real problem with your code.
Run SweetPad's build-server configuration command from the Command Palette and pick your scheme, or run xcode-build-server config manually against your workspace or project and scheme. If the current file seems broken, delete it first and generate a fresh one.
This is usually a PATH problem. VS Code launched from the Dock may not inherit your shell's PATH, so Homebrew's bin directory is missing. Launch VS Code from the terminal, or ensure the tool's directory is on the PATH VS Code uses, then restart it.
Yes. buildServer.json is generated for a specific scheme, so if you pick a framework or test scheme, or one whose build graph excludes the files you edit, completion fails for those files. Regenerate against the scheme that builds your app target.
New dependencies must be built before SourceKit-LSP can resolve their symbols. After adding a Swift package, running pod install, or regenerating the project, build once, wait for indexing, and regenerate buildServer.json if needed.
Open VS Code's output panel and select the SourceKit-LSP channel. The logs show whether it started, found buildServer.json, indexed your files, or hit errors, which usually points directly to the underlying cause.