ConsoleKit gives a Swift command line tool a terminal and a log handler

Two products, not one: the terminal and the logger

ConsoleKit is described as utilities for interacting with a terminal and the command line in a Swift application, and the repository's one line summary is APIs for creating interactive CLI tools.

The package actually ships two, and the split is worth noticing because they are separately declared in your manifest. ConsoleKit itself provides the terminal utilities: sending text, including styles and colors when supported, to a terminal, and reading input from it. ConsoleLogger is a separate product built on top of it, a SwiftLog LogHandler implementation for customizable logging to a console.

The distinction matters for dependency hygiene. A CLI tool that only wants to print a banner and read a line does not need the logging stack, and a service that only wants structured logging does not need terminal input. The manifest makes that choice explicit, one product at a time.

ConsoleLogger is described as a flexible logging backend for console applications, allowing developers to customize log output with various fragments, including timestamps, log levels, and source locations. The fragments phrasing is the interesting part: the output is assembled from pieces you can turn on and off, rather than being a fixed format string.

And because it is a swift-log LogHandler, it plugs into the standard logging facade, which means an application can switch between console and a structured backend without touching its call sites.

Adding it to a Package.swift manifest

Installation goes through Swift Package Manager, and the documentation gives you the manifest line and then the product line separately, which is the part people usually miss.

The dependency itself is added with the repository URL and a version requirement.

.package(url: "https://github.com/vapor/console-kit.git", from: "5.0.0")

Then, in your target's dependencies, you add the product you actually want. For the terminal utilities it is the ConsoleKit product.

.product(name: "ConsoleKit", package: "console-kit")

And for the logging backend it is a different product from the same package.

.product(name: "ConsoleLogger", package: "console-kit")

Both lines name the same package, console-kit, and both can sit in the same manifest if you want both behaviours.

The `from: "5.0.0"` requirement is worth pausing on, because the repository is publishing two lines at once. The listed releases are 5.0.0-beta.3, whose release note reads that it addresses coloured output being broken due to the new build system, 4.16.2 from the same day, and 5.0.0-beta.2 from 2026-08-11. So the 4.x line and the 5.0 beta line are both live, and a manifest that asks for from 5.0.0 will land on a pre-release until the stable 5.0 ships, while a manifest pinned to 4.16.2 stays on the older line.

Swift 6.2 is the floor, and every platform it supports comes along

The supported platforms statement is short: ConsoleKit supports all platforms supported by Swift 6.2 and later.

That is a different kind of commitment from naming a list of operating systems. It means the tool is tested wherever the compiler runs, which for server-side Swift includes Linux, and the repository's topics list includes server-side-swift, swift-linux and swift-log, so this is a package built for a server context rather than for a Mac application.

The badge in the header says Swift 6.2+, which matches the prose. Practically, it means adopting ConsoleKit also means adopting a recent Swift toolchain, and it means your CI matrix has to cover the platforms you claim to support rather than just your laptop.

The repository layout is small and consistent with a focused library. There is Sources/ and Tests/, a Package.swift, a Benchmarks/ directory, a LICENSE, a .swift-format configuration for the formatter, and a .spi.yml file, which is the manifest format used by the Swift Package Index for publishing server-side packages. That last file is a small signal of intent: the package is meant to be indexed and consumed by other server-side projects, not used from a single app.

What the documentation does not tell you

The README here is short, and the gaps are the sort that a Swift developer will notice immediately.

There is no example of console output. The description says the utilities handle text including styles and colors, when supported, and it links to the API documentation at api.vapor.codes/consolekit/, but it does not show what a styled line looks like, which style attributes exist, or how the colour detection behaves when the output is piped to a file rather than a terminal.

There is also no example of the logging side. ConsoleLogger is described as customizable with fragments such as timestamps, log levels and source locations, but the README does not show what those fragments look like, how they are composed, or what the default output is. The swift-log documentation would explain the handler contract, and the linked API reference would fill in the rest, but a reader starting from the repository has to go elsewhere to learn the shape of the thing.

What the README does say is that the project aims at interactive CLI tools, which is a design constraint worth taking seriously. A library aimed at interactive tools has to deal with a terminal that may or may not support colours, input that may arrive from a pipe, and output that may be redirected. That kind of work is exactly the kind you do not want to write per project, and it is also exactly the kind that is hard to document in a paragraph.

So the assessment is: this is a well-scoped dependency with thin top-level documentation, which is normal for a utility library inside a larger framework family.

Where it sits next to swift-log and the rest of Vapor

The relationship with the wider Vapor ecosystem is the main reason to pick this package over something ad hoc.

The most direct comparison is with using swift-log alone. swift-log is the logging facade, and any package can provide a LogHandler for it. Writing your own console handler is a well-understood exercise: format the message, write to standard error or standard output, flush. What ConsoleLogger adds is the fragment system, so the same handler can be told to include a timestamp, a level and a source location without every call site changing.

The second comparison is with writing terminal interaction yourself. Reading a line, echoing it, and colouring output means handling terminal capabilities, and those capabilities are exactly the kind that differ between a tty, a pipe and a CI log collector. ConsoleKit centralises that in a package the Vapor team maintains and publishes.

The third is with the general pattern of a full terminal UI framework. This is not one of those. The description mentions utilities for sending text and reading input, and nothing about widgets, cursor control, layouts or rendering surfaces. If you are building a full screen application with panels and keyboard navigation, this is the wrong layer and you want a different dependency. If you are building a tool that prints a table, asks a question and exits, this is exactly the right size.

Licence, cadence and the 5.0 line

The licence is MIT, with the LICENSE file at the repository root and the badge in the header.

The release history shows two tracks. The stable line is at 4.16.2, released 2026-10-19. The 5.0 line is at 5.0.0-beta.3, released 2026-10-19, with the note that it addresses coloured output being broken due to the new build system, and 5.0.0-beta.2 from 2026-08-11.

That note is the most useful thing in the release list, because it describes a real class of problem. A build system change broke coloured output, and a beta exists to work around it. If you are on the 4.x line today, your coloured output works. If you move to 5.0.0-beta.3, the project is telling you the breakage is fixed, and a beta is where you find out whether it is fixed for your terminal and your pipeline.

The last push was on 2026-10-20 and the repository is not archived, and there is a continuous integration badge plus a code coverage badge, so the package is tested and measured as a library rather than as a script.

The practical advice follows from the two-track release. Treat 4.16.2 as the safe choice for a production CLI, read the 5.0 release notes when the stable tag lands, and if you are a package author on the server-side side, watch the Swift Package Index entry, because the .spi.yml file is there so that the package is discoverable by the tooling the rest of the server-side ecosystem uses.

Editorial conclusion

ConsoleKit fits a Swift team building a command line tool, or a Vapor service that needs an interactive admin command, and who would rather use the framework's own terminal and logging code than wire up swift-log handlers and ANSI escapes by hand. It does not fit a team that wants a rich terminal UI, because the documentation here describes utilities for text and input rather than a widget toolkit, and it does not fit a project on Swift below 6.2. Before adopting it, check whether your build resolves the 5.0.0 beta or the 4.16.2 release, since the repository is publishing both lines and the beta exists partly because coloured output was broken by a new build system, and read the 5.0 release notes before moving a production CLI onto the new major version.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. vapor/console-kit on GitHub