Swift, the upstart language poised to cement itself amongst the most-used in the industry, will soon support the Language Server Protocol (LSP).

On its surface, this news may sound like a language gaining a new feature, but it’s far more than that. LSP allows languages to run on multiple editors and IDEs, and LSP’s addition to Xcode means other languages can be used more readily within Apple’s own IDE. It conforms to the JSON-RPC protocol, which is a fancy way of saying it uses JSON parsing to do its magic in your favorite IDE on your favorite device.

But what does it all mean? Let’s dissect it.

Red (The Bad Stuff)

Could slow down language updates moving forward.

It’s open source, which could slow down how fast LSP is rolled out.

Provides basic language functionality to IDEs other than Xcode, not a full-fledged ecosystem.

Green (The Good Stuff)

Will make Swift available to more IDEs.

LSP is an addition to SourceKit, too. This will make Xcode better.

Open source means those with the right expertise can contribute.

Helps Swift become far more popular.

Xcode should (re: will) gain the ability to use other LSP languages.

Refactor (Our Take on Swift and LSP)

There’s no denying this is a huge deal. NSHipster says LSP support is “arguably the most important decision Apple has made for Swift since releasing the language as open source in 2014,” and we’re not going to challenge that.

Any critiques have to do with how long it will take to implement. SourceKit LSP is already in beta, and available via GitHub, but far from stable. Xcode doesn’t have it yet. Swift isn’t available on other IDEs yet. It’s early days.

But the upshot is massive. Swift now has the potential to be available on Xcode, Vim, Visual Studio, Atom, Sublime, and other popular IDEs. In a way, this makes good on an earlier promise: When Swift launched, Apple noted it could be used for any purpose, including server-side development. That’s still true, but requires a ground-up build, and many services are already built using other languages and technologies.

A feature written in languages such as Rust or C may need a lot of tweaking with wrappers to find its way to a Swift codebase, which is fine for one-off tooling. With LSP, it is theoretically possible to concurrently code in multiple languages on a favorite IDE, which will make Swift less a pillar for iOS developers and more ubiquitous across the wider development landscape.

It makes Swift available to other IDEs, but also allows Xcode to improve and support other LSP-capable languages. This is not happening immediately; Apple’s “developer tools aficionado” Argyrios Kyrtzidis wrote in a thread that LSP for Xcode is “something that we are interested in, but we don’t have specific plans to announce at this moment.”

This is all about choice. LSP helps both Swift and Xcode get on-par with other IDEs and languages, which is wonderful. Instead of complaining about Xcode, wrappers, and header files, developers will have the ability to work more freely.

We don’t know when full LSP support for the language and/or Xcode will arrive, but our best guess is Swift 5 in 2019. Between full ABI stability and LSP support, the launch of version 5 could end up being a watershed moment for Swift, Apple, Xcode, SourceKit, and the tech community at large.