SourceKitten: a CLI and framework for talking to sourcekitd

The problem SourceKitten solves for Swift tooling authors

Swift tooling needs the compiler's own view of a file: which declarations exist, where they start and end, what a completion at an offset would be, what the doc comment says. That view lives in sourcekitd.framework, which is a C API with an XPC or in-process transport and a request/response model that is not pleasant to call directly. SourceKitten's stated job is to link and communicate with sourcekitd.framework, parse the Swift AST, extract comment docs for Swift or Objective-C projects, and return syntax data for a Swift file. The audience is therefore not app developers. It is people writing linters, documentation generators, mock generators and code generators, and the README lists exactly that kind of consumer: SwiftLint, Jazzy, Sourcery, SwiftyMocky, SourceDocs, Cuckoo, IBAnalyzer and Taylor. If you are writing a script that needs to know the shape of a Swift file, this is the layer that saves you from implementing the sourcekitd protocol. If you are writing an app, it is almost certainly the wrong dependency.

How SourceKitten finds SourceKit and turns it into JSON

The mechanism is resolution plus request. SourceKitten does not bundle sourcekitd. It searches for it in a fixed order: $XCODE_DEFAULT_TOOLCHAIN_OVERRIDE, then $TOOLCHAIN_DIR, then xcrun -find swift, then four well-known Xcode locations under /Applications and ~/Applications, covering both Xcode.app and Xcode-beta.app. On Linux the README states SourceKit is expected at /usr/lib/libsourcekitdInProc.so or at the path named by LINUX_SOURCEKIT_LIB_PATH. That ordering matters: an override variable beats xcrun, so a stale TOOLCHAIN_DIR in a CI environment silently selects a different sourcekitd than the one your build uses. Once resolved, the CLI exposes one subcommand per request type. complete generates code completion options, doc prints Swift or Objective-C docs as JSON, format formats a Swift file, index indexes a Swift file and prints JSON, module-info describes a Swift module, request runs a raw SourceKit request, structure prints Swift structure information as JSON, syntax prints Swift syntax information as JSON, and version prints the current version. Everything comes back as JSON on stdout, which is the real interface: the CLI is a thin serializer over sourcekitd, not a normalized data model.

Installing SourceKitten and running a first structure request

The README gives several install paths. Homebrew is the shortest. The build itself requires Xcode 13.3 or later, or a Swift 5.6 toolchain or later with the Swift Package Manager, and the README notes SourceKitten typically supports previous versions of SourceKit.

brew install sourcekitten

If you would rather build from a checkout, the README says to run swift build in the root directory of the project. The Makefile shows what make install does: it runs swift build --configuration release, resolves the binary through swift build --configuration release --show-bin-path, and installs it into /usr/local/bin by default, with PREFIX and TEMPORARY_FOLDER overridable. There is also a SourceKitten.pkg attached to the releases tab, and a Bazel path that adds an http_archive rule named com_github_jpsim_sourcekitten to your WORKSPACE, after which you run bazel run @com_github_jpsim_sourcekitten//:sourcekitten -- -h.

Once installed, the first useful call is structure, which prints the file's declarations as JSON. The README's own example for the complete subcommand shows the shape of the output: a JSON array whose entries carry keys such as descriptionKey and associatedUSRs.

sourcekitten structure --file file.swift

Expect a JSON object with a top-level key holding nested substructures, each with a kind, a name, a byte offset and a length. Byte offsets are the detail that trips people up: they index into the UTF-8 bytes of the file, not into characters, so slicing a Swift string with them requires care.

Where SourceKitten breaks down in practice

The output schema is sourcekitd's, not SourceKitten's. The README documents subcommands and a completion example, but it does not document a stable contract for the keys those subcommands emit, and it does not document what happens when a request fails against a mismatched toolchain. That is the central trade-off: you get the compiler's real view, and you inherit its churn. A structure request that works against one Xcode can return different keys against the next, and the README's compatibility statement is only that SourceKitten typically supports previous versions of SourceKit. The resolution order compounds this. Because $TOOLCHAIN_DIR and $XCODE_DEFAULT_TOOLCHAIN_OVERRIDE take precedence over xcrun, a build agent with either variable set can run a sourcekitd that has nothing to do with the Xcode selected by xcode-select, and the failure surfaces as missing keys rather than as a clear error. There is also a platform boundary: on Linux you supply libsourcekitdInProc.so yourself, either at the expected path or through LINUX_SOURCEKIT_LIB_PATH, and the README does not describe rollback or fallback if that library is absent. Finally, if you only need to parse Swift syntax and do not need compiler semantics, a parser-based approach avoids the whole toolchain coupling problem.

SourceKitten compared with SwiftSyntax for parsing Swift

The real alternative for many SourceKitten use cases is SwiftSyntax, which people also search for alongside this project. The difference in approach is where the truth comes from. SourceKitten asks a running sourcekitd, the compiler's own service, so the answers reflect the compiler's semantic understanding: type information, resolved declarations, completion candidates at an offset, doc comments as the compiler sees them. SwiftSyntax parses source text into a syntax tree in process, with no sourcekitd, no Xcode search path and no toolchain override variables, but it gives you syntax rather than compiler semantics. In exchange you get a versioned library you depend on through SwiftPM, so the API you compile against is the API you get. Choose SourceKitten when you need completion, module info or the compiler's view of an expression; choose SwiftSyntax when you need to walk declarations and do not want a toolchain dependency. The projects listed in the README sit on the SourceKitten side because they need exactly the semantic layer.

Maintenance, licence and what an upgrade costs you

The repository is not archived and the last push was on 2026-08-09, with release 0.38.0 published on 2026-07-26. The release cadence visible in the recent history is uneven: 0.37.2 on 2025-06-16, then 0.37.3 on 2026-03-30, then 0.38.0. That matters for planning, because a sourcekitd-facing tool has to keep pace with Xcode. The upgrade cost is not in SourceKitten's own API, which is a set of subcommands and a framework, but in the JSON your code parses and in the toolchain you resolve against. Budget for re-running your parser against each new Xcode before you ship it. The project is MIT licensed, which is permissive and imposes no copyleft obligation on your own code; the README does not discuss relicensing, and nothing available suggests a change. If you redistribute the binary, check the licence text in the repository rather than relying on this summary, and note that the licence covers SourceKitten, not the Apple toolchain it loads at runtime.

Editorial conclusion

Adopt SourceKitten if you are building Swift tooling that needs structure, syntax, docs or completion data and you can pin a toolchain: SwiftLint, Jazzy, Sourcery and SourceDocs are built on it. Do not adopt it if you want a stable, versioned schema, because the CLI prints raw sourcekitd output that shifts with the toolchain, and the README documents no compatibility guarantee beyond the Xcode 13.3 or Swift 5.6 build floor. Before committing, run sourcekitten structure on a file that uses recent language features against the exact Xcode you ship with, and check the JSON keys your parser depends on.

Frequently asked questions

Official sources

1. Issues
2. jpsim/SourceKitten on GitHub
3. License: MIT
4. README
5. Releases