For years, writing Swift meant writing it in Xcode. That era is ending.
On June 24, 2025, the Swift project announced a sweeping initiative to bring first-class IDE support to any editor capable of speaking the Language Server Protocol — Visual Studio Code, Neovim, Emacs, and others. The effort, detailed in a blog post on swift.org, represents the most significant investment Apple’s open-source programming language has made in meeting developers where they already work, rather than asking them to adopt a specific tool.
The implications are substantial. Swift has long been perceived as an Apple-platform language, tethered to macOS and iOS development through Xcode’s gravitational pull. Server-side Swift exists. Swift on Linux exists. Swift on Windows exists. But the tooling story outside Xcode has been, to put it charitably, incomplete. That’s what this initiative aims to fix — not incrementally, but comprehensively.
At the center of the announcement is SourceKit-LSP, the language server that acts as the bridge between Swift’s compiler intelligence and third-party editors. SourceKit-LSP has existed since 2018, but it operated with limited resources and lagged well behind what Xcode could offer. The new plan pours engineering effort into closing that gap. According to the swift.org post, the project will expand SourceKit-LSP’s capabilities to include features developers have come to expect from modern IDEs: macro expansion, more accurate code completion, improved indexing, and better cross-module navigation.
But the ambitions go further than just upgrading a language server.
The Swift team is also building what it calls a “Swift for VS Code” extension — not a thin wrapper around SourceKit-LSP, but a purpose-built experience designed to make Visual Studio Code a genuinely productive environment for Swift development. This includes integrated debugging, package resolution for Swift Package Manager, and test discovery. The extension already exists in an early form, but the roadmap described in the blog post suggests it will mature rapidly, with background indexing, live diagnostics, and refactoring support all on the near-term horizon.
Why now? The timing isn’t accidental. Swift’s server-side ambitions have been growing steadily. Vapor, the most popular Swift web framework, continues to gain traction. Apple’s own Distributed Actors framework targets server and cloud workloads. And the language’s recent push into embedded systems — announced at WWDC 2024 with Embedded Swift — means developers are increasingly working on platforms where Xcode simply doesn’t run. A Linux kernel developer experimenting with Swift isn’t going to install macOS to get code completion.
The Language Server Protocol, created by Microsoft and now an open standard, is what makes this possible at a technical level. LSP defines a JSON-RPC protocol that editors use to communicate with language-specific backend servers. When a developer hovers over a function name in VS Code, the editor sends a request to the language server, which responds with type information, documentation, or diagnostics. The protocol has become the lingua franca of modern editor tooling, and languages that invest heavily in their LSP implementations — Rust with rust-analyzer, Go with gopls — tend to see their developer communities expand beyond any single IDE.
Swift’s SourceKit-LSP has been functional but frustrating. Developers on the Swift forums and on X have long reported issues with indexing accuracy, slow response times on large projects, and missing features that Xcode handles effortlessly. The new initiative directly acknowledges these shortcomings. The swift.org blog post states that the team plans to “bring the quality and feature set of Swift’s open-source IDE support to the same level that developers expect from other modern languages.”
That’s a high bar. And it’s the right one.
Consider what Rust’s rust-analyzer offers: instant diagnostics, inline type hints, automated refactoring, proc-macro expansion, and near-instant code completion even on large codebases. It took years of dedicated work to reach that level. Swift’s compiler architecture, with its reliance on the SourceKit framework originally built for Xcode, presents different challenges. SourceKit was designed as a monolithic service tightly coupled to Apple’s IDE. Extracting its intelligence into a standalone, cross-platform server has been an ongoing engineering project, and the results so far have been mixed.
The new plan appears to tackle this head-on. Background indexing — the ability to build a project-wide index without requiring the developer to compile first — is one of the headline features. Without it, code navigation in large Swift projects is essentially broken in non-Xcode editors. You open a file, try to jump to a definition in another module, and nothing happens. Or worse, you get sent to the wrong place. Background indexing would build the index incrementally as files change, keeping the editor’s understanding of the codebase current without manual intervention.
Debugging support is another critical piece. The Swift team is investing in the Debug Adapter Protocol (DAP), a companion standard to LSP that provides a uniform interface for debuggers across editors. Swift already uses LLDB for debugging, but the integration with VS Code and other editors through DAP has been minimal. The plan calls for a fully integrated debugging experience — breakpoints, variable inspection, REPL evaluation — that works without Xcode.
The community response has been enthusiastic, bordering on relieved. On the Swift forums, developers who work on Linux-based server deployments have been particularly vocal. One long-running thread on the forums discusses the challenges of using Swift in Docker containers for CI/CD pipelines, where the lack of proper editor tooling makes debugging and development painful. The announcement directly addresses these pain points.
On X, reactions from prominent Swift developers reflected a similar sentiment. The general consensus: this should have happened sooner, but better late than never. Several developers noted that the announcement could meaningfully expand Swift’s adoption among backend engineers who currently default to Go, Rust, or TypeScript — languages where VS Code support is already excellent.
There’s a strategic dimension here too. Apple doesn’t control VS Code. Microsoft does. By investing in VS Code as a first-class Swift development environment, Apple is implicitly acknowledging that its own IDE monopoly over Swift development was becoming a liability. Developers who might otherwise try Swift for a server project have been deterred by the tooling story. “I’d love to use Swift, but I’m not switching to Xcode for backend work” is a sentiment that’s appeared in countless forum threads, Reddit discussions, and conference hallway conversations.
The announcement also signals a maturation of the Swift open-source project itself. When Apple open-sourced Swift in 2015, the promise was that it would become a truly community-driven language. In practice, Apple’s internal priorities — iOS, macOS, watchOS, visionOS — have dominated the roadmap. The IDE support initiative is different. It’s explicitly aimed at developers who may never write an iOS app. That’s a meaningful shift in priorities, even if Apple doesn’t frame it that way.
So what does the timeline look like? The blog post doesn’t give hard dates, but it describes a phased approach. Immediate improvements to SourceKit-LSP are already landing in nightly toolchain builds. The VS Code extension is receiving active development with regular updates. Longer-term features like full refactoring support and macro expansion will come later, likely aligned with Swift’s regular release cadence.
There are risks. The biggest is execution. Apple has announced ambitious open-source tooling initiatives before, and some have languished. The Swift Package Manager, for instance, took years to reach feature parity with CocoaPods and Carthage for basic dependency management tasks. SourceKit-LSP itself was announced with fanfare in 2018 and then received only sporadic attention for several years. Developers will be watching closely to see if this time is different.
Another risk is fragmentation. If the VS Code experience diverges significantly from Xcode’s — different diagnostics, different code completion behavior, different refactoring capabilities — developers working across both environments will face constant friction. The Swift team seems aware of this, noting in the blog post that the goal is to share as much compiler infrastructure as possible between Xcode and open-source tooling. But shared infrastructure and identical behavior are two different things.
And then there’s the question of resources. Rust’s rust-analyzer project has dozens of contributors and dedicated funding. The Go team at Google employs engineers who work full-time on gopls. If Apple wants Swift’s open-source IDE tooling to compete at that level, it will need sustained investment — not a burst of activity followed by benign neglect.
For the broader Swift community, the announcement is a clear signal: the language’s future isn’t confined to Apple platforms. Swift on the server. Swift for command-line tools. Swift in embedded systems. Swift for cross-platform libraries. None of these use cases are new, but all of them have been held back by tooling that assumed Xcode was always in the picture. Removing that assumption doesn’t guarantee Swift’s success in these domains. But it removes one of the most persistent barriers.
The real test will come in six months, when developers who download the latest Swift toolchain and open VS Code can judge for themselves whether the experience has actually improved. Code completion that works. Diagnostics that appear instantly. Jump-to-definition that lands in the right place. These aren’t flashy features. They’re table stakes. And for Swift outside of Xcode, they’ve been missing for far too long.
WebProNews is an iEntry Publication