Toward a Shared Swift-Native LSP Infrastructure Layer for Editor Integration

[furbytm]

Summary

Following discussion in coteditor#1524, I wanted to open a broader architectural exploration around whether Language Server Protocol support in CotEditor could potentially benefit from being built on top of a reusable Swift-native LSP client infrastructure layer, rather than a tightly editor-coupled implementation, (reference here).

Over the past few years, I’ve intermittently explored what improving Swift LSP support outside of Xcode could look like - including experiments around editors such as Zed and other lightweight Swift-native tooling environments.

One recurring observation is that the majority of implementation complexity does not appear to come from Swift-specific language functionality itself, but from the shared LSP runtime/client responsibilities that every editor ends up needing to solve independently.

These commonly include:

• JSON-RPC transport
• stdio/socket process management
• async request/response routing
• cancellation semantics
• text document synchronization
• diagnostics pipelines
• completion and hover plumbing
• semantic token decoding
• workspace coordination
• capability negotiation
• indexing lifecycle management

This raises an architectural question:

Would it be more beneficial long-term for editors like CotEditor to integrate with a shared Swift-native LSP infrastructure layer, rather than each editor independently implementing and maintaining its own protocol/runtime stack?

Goals

The intent here would not be to create a heavyweight IDE framework or editor abstraction layer.

Instead, the focus would be a lightweight, modular, editor-agnostic runtime layer responsible for:

let client = LSPClient(
    server: .process("/usr/bin/sourcekit-lsp")
)

with editors providing their own UI/document adapters on top.

Potential areas of responsibility could include:

• LSP transport/runtime management
• Codable-backed protocol models
• Swift concurrency-based request handling
• diagnostics/event streams
• workspace/session lifecycle
• semantic token parsing
• server capability negotiation

while remaining:

• AppKit-neutral
• SwiftUI-neutral
• UIKit-neutral
• language-server agnostic

Potential Benefits

Shared ecosystem infrastructure

A reusable layer could potentially benefit:

• CotEditor
• lightweight Swift-native editors
• internal tooling
• educational IDEs

instead of each project independently re-solving similar infrastructure concerns.

Better Swift ecosystem interoperability

A common client/runtime layer may help encourage:

• more consistent LSP behavior
• improved SourceKit-LSP integration quality
• shared bug fixes
• faster experimentation
• reduced maintenance burden

across multiple editors and tools.

At minimum, I think this may be an interesting architectural discussion for the broader Swift tooling ecosystem — especially as more Swift-native editors and developer tools continue emerging outside of Xcode.

[furbytm]

See also, related existing projects such as:

• https://github.com/ChimeHQ/LanguageClient

[furbytm]

After further review, the following is what appears to be missing at an ecosystem level:

• A document synchronization adapter layer - translating editor text engine mutations to LSP incremental edits, decoupled from any specific editor's internal model. ChimeHQ has done a lot of work in this space - ChimeKit's ChimeLSPAdapter does this work for Chime's own extension model, but an editor-agnostic equivalent decoupled from any specific editor architecture doesn't appear to exist yet.

• A workspace resolution heuristic library for editors that lack project models - crawling up the directory tree to find Package.swift, .xcodeproj, etc., and managing the workspaceFolders lifecycle accordingly. This gap shows up beyond Swift editors too: even in Zed, a mature Rust-based editor with its own LSP infrastructure, getting full Swift support for Xcode projects requires a manual community workaround (xcode-build-server) to bridge the Build Server Protocol gap that sourcekit-lsp alone can't solve. The workspace context problem is a broader ecosystem issue.

• An editor-agnostic diagnostics annotation model - a thin data layer that maps LSP diagnostic responses to range-based annotations with no AppKit/UIKit assumptions, leaving rendering entirely to the editor.

Note

ChimeHQ/Neon addresses semantic token highlighting well, though diagnostics remain a separate unaddressed concern.

[furbytm]

@mattmassicotte - given your work in this space, I am curious if you have any thoughts on these gaps or ideas on how the existing ChimeHQ pieces could compose toward this.