# vscode-swift: the official Swift language support for VS Code

> The swiftlang/vscode-swift extension gives Visual Studio Code Swift language support through SourceKit LSP, with debugging through the separate LLDB DAP extension and a project panel for dependencies. Its scope is Swift Package Manager projects, since Xcode project support is explicitly limited, and the repository also publishes an API other extensions can consume.

**swiftlang/vscode-swift** — Visual Studio Code Extension for Swift

- Repository: https://github.com/swiftlang/vscode-swift
- Website: https://marketplace.visualstudio.com/items?itemName=swiftlang.swift-vscode
- Stars: 1,072 · Forks: 126
- Language: TypeScript
- License: Apache-2.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/swiftlang-vscode-swift

## Language support with a stated boundary

The Swift for Visual Studio Code extension adds language support for Swift to Visual Studio Code, covering Swift development on all supported platforms.

The feature list is the standard one for a language extension, and it is worth reading the individual items because the extension does more than syntax highlighting. There is code completion. There is jump to definition, peek definition, find all references and symbol search. There are error annotations and fix suggestions. There is automatic generation of launch configurations for debugging with the LLDB DAP extension, and automatic task creation. There is a Project Panel to quickly run actions and view dependencies. And there is a Test Explorer view.

The Project Panel and the automatic launch configuration generation are the two that go beyond what a plain language server gives you, and both are aimed at the same problem: a Swift project on a machine that is not running Xcode. Without Xcode there is no scheme file, no build system UI and no test discovery, so an editor has to synthesise them, and that synthesis is the bulk of the work in this extension.

The boundary is stated in a note near the top of the README and it is the most important thing to know before installing: most features of the Swift for Visual Studio Code extension only work with projects that build with Swift Package Manager, which have a Package.swift file in the root folder, and support for Xcode projects, .xcodeproj, is limited.

That is a real constraint rather than a hedge, because the features that need to enumerate targets, products and dependencies are exactly the ones that read the package manifest. An .xcodeproj has a different model, and the extension does not read it in the same way.

The primary language of the repository is TypeScript, the licence is Apache-2.0, the default branch is main, and the last push was on 2026-10-14. The marketplace listing is swiftlang.swift-vscode, and the recent releases are 2.16.7 from 2026-08-18, 2.16.6 from 2026-06-05 and 2.16.5 from 2026-05-27, with the package.json version field reading 2.18.0-dev, so the working tree is ahead of the last published release.

## SourceKit LSP and the LLDB DAP dependency

The extension uses SourceKit LSP as the language server, which powers code completion, and it also has a dependency on the LLDB DAP extension to enable debugging. The LSP link in the README points at the language server protocol overview, and the debugging dependency is a separate marketplace extension rather than something bundled here.

That dependency is worth understanding as a design decision rather than an inconvenience. SourceKit LSP is the language server extracted from the Swift toolchain itself, so it has the same knowledge of the compiler's type system that the compiler has, and the extension gets diagnostics, completions and navigation from the same source of truth the build uses. What SourceKit LSP does not do is launch and drive a debugger, so that job goes to LLDB DAP, the Debug Adapter Protocol front end for LLDB.

The result is a two-extension arrangement. Install the Swift extension for the language features, and the LLDB DAP extension for debugging, and the Swift extension generates the launch configurations that the other one consumes. The README also points at a getting started guide on swift.org and the official extension documentation at docs.swift.org/vscode.

For the person deciding whether to adopt this, the practical consequence is that the debugging story is not self-contained. If you already have the LLDB DAP extension installed, you have debugging. If you do not, you need to add it, and the two are versioned and released independently.

The extension also knows how to get out of the way when it is not needed. The activationEvents in package.json list onLanguage:swift, workspaceContains patterns for Package.swift, compile_commands.json, compile_flags.txt, buildServer.json and .bsp/*.json, and onDebugResolve for swift-lldb and swift. The workspaceContains entries are interesting, because they mean the extension activates for projects that are not Swift packages but that carry a compilation database or a build server description, which are the two ways a non-SPM Swift project exposes itself to a language server.

The extension also requires a reasonably recent VS Code, with the engines field asking for ^1.88.0, and it declares the Programming Languages, Debuggers, Snippets and Testing categories, which is how it appears in the marketplace search.

## The extension API, and why it has its own version number

The extension exports an API for other Visual Studio Code extensions to use, and the design decision in it is the version number.

The API provides access to Swift Toolchains, meaning the active Swift toolchain both globally and on a per-project basis; Swift Projects, meaning a list of all known Swift projects in the active workspace; and SPM Packages, meaning Swift Package Manager targets, products, dependencies and plugins.

The API includes a version number that follows semantic versioning and is separate from the extension's version number, and the contributing guide is pointed at for a detailed explanation of when that version number is incremented. The package.json shows this concretely, with the extension version at 2.18.0-dev and an api-version field set to 1.0.0.

That separation is the point. A consumer extension that depends on the API should be able to say it needs API version 1.2 and have that meaning hold regardless of whether the extension behind it shipped a bug fix or a feature. Without the split, every extension release would be a potential breaking change for every consumer, and there would be no way to express compatibility. The api-version field being at 1.0.0 also says the API is new enough that it has not yet needed a compatibility break, which is a reasonable thing for a recent addition to say.

The usage example shows the shape of the API, and it is worth reading because it shows the extension's mental model of a workspace:

```typescript
import { getSwiftExtensionApi, SwiftExtensionApi } from './SwiftExtensionApi';

// Get the Swift extension API
const api: SwiftExtensionApi = await getSwiftExtensionApi();

// Access workspace context
const workspaceContext = api.workspaceContext;
if (workspaceContext) {
    // Get the toolchain version
    const toolchain = workspaceContext.globalToolchain;
    console.log(`Using Swift ${toolchain.swiftVersion}`);

    // Listen for folder changes
    workspaceContext.onDidChangeFolders((event) => {
        console.log(`Folder operation: ${event.operation}`);
    });
    
    // Access the in focus folder and its Swift package
    const currentFolder = workspaceContext.currentFolder;
    if (currentFolder) {
        const swiftPackage = currentFolder.swiftPackage;
        const targets = await swiftPackage.targets;
        console.log(`Found ${targets.length} targets`);
    }
}
```

The workspaceContext has a globalToolchain, a currentFolder and a change event, and the current folder resolves to a swiftPackage whose targets are awaitable. So the model is workspace, then folders, then packages, then targets.

The README is also careful about how you obtain the type definitions. To use the API in your extension you can download the src/SwiftExtensionApi.ts file from this repository to get proper TypeScript type definitions, and it is recommended that you download the version from a tagged release as main is not guaranteed to remain stable. That is the same reason the API has its own version, applied to the file itself, and it is a sensible instruction that saves consumers a broken build.

## The repository, and the project that grew out of the working group

The top-level listing shows a full Visual Studio Code extension repository rather than a small shim.

There is src/ for the extension source and test/ for the tests, with jest.config.js at the root, so the test suite is JavaScript rather than TypeScript even though the extension is written in TypeScript. The .vscode-test.js file is the VS Code extension test runner configuration, which is the mechanism for running the test suite inside a real VS Code instance rather than in a plain Node process, and .mocha-reporter.js configures its output.

The language support side is present too, with syntaxes/ holding the TextMate grammars, snippets/ holding the code snippets, and two language configuration files, swift-gyb.language-configuration.json and tutorial.language-configuration.json, which is a detail that suggests the extension ships a tutorial mode alongside normal Swift editing.

The tooling around it is thorough. There is an eslint-plugin-vscode-swift/ directory and an eslint.config.mjs, plus .prettierrc.json, .prettierignore, a knip.json for unused dependency checking, and an .unacceptablelanguageignore file, which is an unusual and memorable one. There is a .husky/ directory for git hooks, a .devcontainer/ for a containerised development environment, and .nvmrc and .npmrc for the toolchain. The assets/ directory holds walkthrough images and the tutorial assets referenced by the walkthroughs, and userdocs/ and docs/ hold the documentation.

The governance story is in the Contributing section, and it explains the repository's lineage. The extension is based on an extension originally created by the Swift Server Working Group, it is now maintained as part of the swiftlang organization, and the original extension is deprecated. Contributions of code, tests and documentation are welcome.

That history explains the api-version scheme and the care around the TypeScript definitions. An extension that other extensions consume is a public interface, and the project treats it as one.

## Where vscode-swift is the wrong tool

There are three limits, and the first one is the one the README states outright.

The first is Xcode project support. Most features only work with Swift Package Manager projects, and support for .xcodeproj is limited. For a developer whose work is a large Xcode project on macOS, with an app target, a test target, signing settings and a scheme, this extension is a partial answer. The features that need to enumerate targets and dependencies are precisely the ones that read Package.swift, so an .xcodeproj user gets the syntax and navigation features and loses the project-level ones.

The second is the debugging arrangement. Debugging depends on a separate extension, the LLDB DAP one, and the Swift extension's contribution is to generate launch configurations. The generated configuration is a starting point, and a project with unusual build settings, multiple schemes or a custom working directory will need the configuration edited, and the README does not describe the options the generator produces. Compare that with Xcode, where the scheme editor is the product.

The third is that the language server has to be able to build your package. SourceKit LSP indexes a Swift package by asking the toolchain to load it, which means the dependency resolution has to succeed, which means the network and the toolchain and the package manifest all have to agree. When that does not happen, the diagnostics and the completions degrade or disappear, and the failure is reported in the language server's own channel rather than in the editor's, which is where a new user will look least.

There is also the platform point that the README's phrase on all supported platforms glosses over. The extension is at its best on Linux and on Windows, where a Swift toolchain is installed by hand and there is no competing editor tooling. On macOS, Xcode remains the more complete environment, and the case for this extension there is portability, or working on a Swift package that is shared with colleagues on other platforms, or a preference for a lighter editor.

And a licensing point, briefly. The extension is Apache-2.0, with the LICENSE file at the root and a NOTICE.txt beside it, which is the permissive terms most organisations want. The code of conduct is the Contributor Covenant, referenced through swift.org, and that is a sign of a project that expects outside contributions and has a process for them.

## vscode-swift against the alternatives

There are three real alternatives, and the differences in approach are about how much of the toolchain you are willing to give up.

The first is Xcode itself, on macOS. It is the reference implementation of the toolchain, it ships the compiler, the debugger, the build system and the test runner as one integrated product, and every feature the extension has to synthesise is a feature Xcode has natively. The difference in approach is that Xcode is a closed vertical stack and this extension is an open front end to the same underlying tools, using SourceKit LSP for the language and LLDB for the debugger.

The second is the other language-server path, which is what happens when you do not want a VS Code dependency. The Swift toolchain includes sourcekit-lsp, and there are extensions for other editors that wrap the same server, so the capability is not exclusive to this extension. What this extension adds is the surrounding work: the Project Panel, the automatic task creation, the generated launch configurations and the test explorer. A team that only needs completion and diagnostics does not need any of that.

The third is a different kind of tool. A build-and-run workflow driven from the command line, with an editor used only for editing, is a legitimate approach for Swift server-side packages, and the toolchain's own swift build and swift test commands cover the same ground as the Test Explorer view.

So the decision comes down to what you are missing. On macOS with an Xcode project, Xcode has more and integrates better, and the extension's value is portability rather than capability. On Linux or Windows, the extension is how you get a Swift development environment at all. And if your work is a Swift package that has to build identically for every platform, having one editor workflow across them is the argument for this extension over an IDE, which is also why the SPM-only limitation bites less in that case.

## Conclusion

Adopt vscode-swift if you write Swift on a platform where Xcode is not the tool, or you want an editor-agnostic Swift workflow, and your projects are Swift Package Manager based. Do not expect it to replace Xcode for Apple-platform work, since the README states support for .xcodeproj is limited. Verify first that your toolchain is discoverable, that the LLDB DAP extension is installed alongside it for debugging, and that the source kit server can index your package before you judge the completion quality.

## FAQ

### Does vscode-swift support Xcode projects?

Only in a limited way. The README states that most features of the extension only work with projects that build with Swift Package Manager, which have a Package.swift file in their root, and that support for .xcodeproj is limited.

### What does the vscode-swift extension need for debugging?

It has a dependency on the separate LLDB DAP extension, and the Swift extension automatically generates launch configurations for it to use. Language features such as code completion come from SourceKit LSP.

### Can another VS Code extension use the Swift extension API?

Yes. It exposes Swift toolchains, Swift projects and SPM package information, and the API has its own semantic version number, separate from the extension version, so consumers can state their compatibility requirement.

### Where should I get the Swift extension API type definitions?

The README says to download src/SwiftExtensionApi.ts from the repository, and recommends taking the version from a tagged release because main is not guaranteed to remain stable.

## Sources

- [License: Apache-2.0](https://github.com/swiftlang/vscode-swift/blob/main/LICENSE)
- [Project website](https://marketplace.visualstudio.com/items?itemName=swiftlang.swift-vscode)
- [README](https://github.com/swiftlang/vscode-swift/blob/main/README.md)
- [Releases](https://github.com/swiftlang/vscode-swift/releases)
- [swiftlang/vscode-swift on GitHub](https://github.com/swiftlang/vscode-swift)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/swiftlang-vscode-swift