A step-by-step guide to installing and configuring SweetPad in Visual Studio Code, including Xcode prerequisites, the xcode-build-server helper, and the supporting extensions you need for a working iOS workflow.
SweetPad is a front end for Apple's toolchain, so the prerequisites matter more than the extension itself. First, you need a Mac running macOS — there is no way around this, because the iOS SDKs and Simulator are macOS-only. Second, install the full Xcode application from the Mac App Store, not just the Command Line Tools, because SweetPad relies on the SDKs, Simulator runtimes, signing infrastructure, and xcodebuild that ship with Xcode. Launch Xcode once after installing so it can finish installing additional components and accept the license agreement. Third, make sure the active developer directory points at Xcode by running xcode-select -p and confirming it returns a path inside your Xcode app; if not, run sudo xcode-select -s /Applications/Xcode.app. Finally, install Visual Studio Code itself. With Xcode present and selected, VS Code installed, and at least one Simulator runtime available, you have the foundation SweetPad needs before you install a single extension.
With VS Code open, install SweetPad from the Extensions view. Open the Extensions sidebar with the puzzle-piece icon or the standard shortcut, search for SweetPad, and install the extension published by the SweetPad project. You can also install it directly from the Visual Studio Marketplace in a browser. After installation, SweetPad adds a dedicated activity-bar icon and registers a set of commands you can reach through the Command Palette by typing SweetPad. It is worth opening the palette and browsing those commands now so you know what is available: you will see entries for building, cleaning, running, selecting a destination, and generating the build-server configuration. SweetPad does not need any API key or login. At this stage the extension is installed but not yet fully functional, because code completion and building both rely on additional command-line helpers and configuration that we install next. Do not skip those steps, or you will get an editor that opens Swift files but offers no completion and cannot build.
SweetPad delegates real work to command-line tools, and the two you most likely need are xcode-build-server and a Swift formatter. The recommended way to install them on macOS is Homebrew. If you do not already have Homebrew, install it from brew.sh first. Then install the build server with brew install xcode-build-server. This tool bridges your Xcode project to SourceKit-LSP, which is what powers accurate code completion and jump-to-definition. For formatting, install a formatter such as SwiftFormat with brew install swiftformat, or use Apple's swift-format if you prefer. If you plan to debug, also install the CodeLLDB extension in VS Code, because SweetPad uses it to attach LLDB for breakpoints and stepping. After installing these tools, confirm they are on your PATH by running xcode-build-server --help and swiftformat --version in a terminal. If a command is not found, reopen your terminal or check that Homebrew's bin directory is in your PATH so both SweetPad and your shell can locate the tools.
SweetPad expects to work against a real Xcode project or workspace, so open the folder that contains your .xcodeproj or .xcworkspace in VS Code, typically the repository root. If your project uses CocoaPods or a Swift package with an accompanying workspace, open the folder holding the .xcworkspace, because that is the file xcodebuild should target. If you generate your project with Tuist or XcodeGen, run that generation step first so the project files exist on disk before SweetPad tries to read them. Once the folder is open, SweetPad can scan for schemes and build configurations. It is a good habit to make sure the project already builds in Xcode at least once, since that confirms your signing, dependencies, and scheme are healthy and isolates any later problems to the SweetPad layer rather than the project itself. A project that cannot build in Xcode will not build through SweetPad either, because the same xcodebuild runs underneath.
Code completion in VS Code comes from SourceKit-LSP, and SourceKit-LSP needs to know how your project is built. That information lives in a file called buildServer.json at the root of your project, produced by xcode-build-server. SweetPad can generate it for you: open the Command Palette and run the SweetPad command that creates the build-server configuration, then choose the scheme you want indexed. Under the hood this runs xcode-build-server config against your project or workspace and writes buildServer.json. You can also generate it manually from a terminal with the xcode-build-server config command, passing your workspace or project and scheme. Once the file exists, SourceKit-LSP can read compiler arguments for each Swift file and provide completion, diagnostics, and navigation. Do not commit machine-specific absolute paths carelessly; many teams gitignore buildServer.json because it references local build directories. If you change schemes, add targets, or restructure the project, regenerate the file so indexing stays accurate.
Before your first build, tell SweetPad what to build and where to run it. Using the Command Palette or the SweetPad sidebar, select the scheme that corresponds to the app you want to run — the same schemes you would see in Xcode's scheme selector. Then select a destination, which is either an available iOS Simulator or a connected physical device. The list of Simulators comes from the runtimes installed with Xcode, so if you see no options, open Xcode and add a Simulator runtime through its settings. Choosing a scheme and destination is the equivalent of Xcode's run-target selector, and SweetPad passes these values to xcodebuild as the -scheme and -destination arguments. Getting this right up front avoids the most common first-run confusion, where a build succeeds but nothing launches because no destination was chosen. With a scheme and a Simulator destination selected, you are ready to run your first build-and-run from VS Code, which is covered in the companion guide.
Once building works, spend a few minutes on the ergonomics that make SweetPad worth using day to day. If you installed SwiftFormat or swift-format, wire it into VS Code so Swift files format on save; SweetPad can invoke the formatter, and you can set editor.formatOnSave for Swift in your settings so the format runs automatically. Keep a project-level .swiftformat or .swift-format configuration file in the repository so every developer formats identically and you avoid noisy diffs. Next, bind SweetPad's build and build-and-run commands to keyboard shortcuts through VS Code's keyboard-shortcuts editor, mirroring the run shortcut you already have in muscle memory from Xcode. This turns the write-build-run loop into a single keystroke and removes the friction of hunting through the Command Palette each time. Consider also installing companion extensions you already rely on — a Swift syntax extension, GitLens, and error-lens — so the editor feels complete. These are optional but they are the difference between a bare setup and one that genuinely competes with Xcode's inner loop for editing.
Finish by verifying each layer works. Open a Swift file and confirm you get code completion and inline diagnostics after a few seconds of indexing; if not, your buildServer.json or SourceKit-LSP setup needs attention. Run a SweetPad build and watch the integrated terminal or output panel to confirm xcodebuild runs and completes without configuration errors. Then run build-and-run against a Simulator and confirm the Simulator boots and your app launches. If you intend to debug, set a breakpoint and start a debug session to confirm CodeLLDB attaches. Working through these checks in order tells you exactly which layer to fix if something fails: the editor layer (SourceKit-LSP and buildServer.json), the build layer (xcodebuild, scheme, signing), or the run layer (destination and Simulator runtime). Keep Xcode installed and occasionally open it for tasks SweetPad does not cover, such as asset catalogs, storyboards, and signing configuration, since SweetPad is a companion to Xcode rather than a full replacement.
You need the full Xcode application. SweetPad depends on the SDKs, Simulator runtimes, and signing infrastructure that come only with full Xcode. The Command Line Tools alone are not sufficient for building and running iOS apps.
The simplest method on macOS is Homebrew: run brew install xcode-build-server. After installing, verify it is on your PATH with xcode-build-server --help. SweetPad uses it to generate buildServer.json so SourceKit-LSP can provide code completion.
At the root of your project, alongside the .xcodeproj or .xcworkspace. SweetPad can generate it via a Command Palette command, or you can run xcode-build-server config manually. Many teams gitignore it because it can reference local build paths.
Open the folder that contains your project or workspace, usually the repository root, so SweetPad and SourceKit-LSP can see the whole project. If you use CocoaPods or a workspace, make sure the .xcworkspace is present and targeted.
That usually means no Simulator runtime is installed. Open Xcode, add an iOS Simulator runtime through its settings or platform downloads, then reselect the destination in SweetPad. The Simulator list comes directly from Xcode's installed runtimes.
You need CodeLLDB only if you want to debug with breakpoints and stepping, since SweetPad uses it to attach LLDB. Building and running without debugging does not strictly require it, but most developers install it for a complete workflow.