SwiftFormat: a Swift code formatter for the command line, Xcode and CI

What SwiftFormat actually rewrites

A formatter that only moves whitespace is a solved problem. SwiftFormat's README makes a larger claim: it "goes above and beyond what you might expect from a code formatter," and the examples it gives are semantic rather than cosmetic. It can insert or remove implicit self, remove redundant parentheses, and correct what the project calls deviations from standard Swift idioms.

That distinction decides who the tool is for. Inserting self changes what a closure captures and what a reader sees; removing parentheses changes nothing at runtime but changes how the expression reads. Both are edits a reviewer would otherwise have to request by hand, and both are the kind of request that starts arguments on a team where some people care about style and some do not. The README frames the motivation exactly that way: enforcing a style manually is "tedious and error-prone," and a tool removes the argument.

The audience is therefore Swift teams, not individual hobby projects. A single developer with a consistent hand does not need a formatter. A repository with several contributors, a CI pipeline and a code review culture does, because the alternative is a style debate on every pull request.

Rules, options and the config file that pins them

SwiftFormat separates two things that other tools merge. Options control formatting behaviour such as indentation width. Rules are the individual transformations, and the README links a full rules reference at swiftformat.info/rules. A config file records which of each you want, so the decisions live in the repository instead of in each developer's shell history.

The README's own installation section shows the option style in a shell alias: `--indent 4`. Running `swiftformat --help` lists what is available. Because the tool ships a `.swiftformat` file at the root of its own repository, the project uses the same mechanism it asks you to use.

Two configuration surfaces matter for adoption. The first is the Swift version. The README documents a `Swift version` setting, and formatting rules that depend on language features need to know which language you are compiling against; a codebase still on an older toolchain will not want rules that assume newer syntax. The second is globs, which decide which files are in scope. Both are the settings most likely to produce a surprising diff on a first run.

Linting is the other mode. The README documents a linting section and a set of error codes, which is what makes the tool usable as a CI gate rather than only as an editor convenience. The README also documents a cache and file header handling, and a markdown formatting capability, so the tool is not strictly limited to .swift files.

Installing SwiftFormat and formatting a first file

The README lists several installation routes. On macOS or Linux with Homebrew already present, the command is one line. The README gives this example:

$ brew install swiftformat

Mint is the other package-manager route the README documents:

$ mint install nicklockwood/SwiftFormat

If you would rather build from source, the README gives a three-command sequence that works on macOS, Linux and Windows. It clones the repository, enters it, and builds a release binary:

$ git clone https://github.com/nicklockwood/SwiftFormat
$ cd SwiftFormat
$ swift build -c release

The README also documents a Nix devShell using `pkgs.swiftformat` from nixpkgs, a CocoaPods route, and a `.binaryTarget` entry for `Package.swift` that points at a release artifactbundle with a checksum. For a first real use, run the tool over a directory and see what it would change before letting it write. The README documents a dry-run mode for exactly this; check `swiftformat --help` for the flag spelling in your installed version, since the README's alias example is where the option names are shown rather than a full flag list.

Beyond the command line, the README documents an Xcode source editor extension invoked from the Editor > SwiftFormat menu, an Xcode build phase that runs on Cmd-R or Cmd-B, a Swift Package Manager plugin, an Applescript route, plugins for VSCode, Sublime Text and Nova, a Git pre-commit hook, GitHub Actions, Danger on CI, Bazel and a Docker image. The repository ships a `Dockerfile` that builds a static Linux binary and produces a `scratch` image whose entrypoint is `/usr/bin/swiftformat` with a default command of `.`, so the container formats the current directory unless you pass another path.

The first run is the dangerous run

The honest limitation is scope of change. A tool that removes redundant parentheses and adjusts implicit self will produce a diff far larger than a whitespace formatter on a codebase that has never been formatted. That diff is mechanical, but reviewing it is not free, and it will sit in the way of every open branch until it merges. The README does not describe a rollback mechanism, and it does not describe a way to format only the lines a commit touched. Plan the first run as its own change, on a quiet branch, with nothing else in flight.

The second limitation is category. SwiftFormat is not a linter in the sense SwiftLint is. It has a linting mode and error codes, so it can fail a build, but the things it detects are style violations it could also fix. It has no rules about unused variables, retain cycles or API misuse. Teams that want both usually run both, and the README's own table of contents treats linting as a configuration detail rather than the product.

The third is that a config file is a commitment. Rules that are on today may be off tomorrow, and the README documents a cache, which means a run can be faster on the second invocation than the first. Neither of those facts tells you whether a given rule is right for your code. The rules documentation is the place to check, and it is linked from the README rather than reproduced in it.

SwiftFormat and SwiftLint are not substitutes

The comparison people search for is SwiftFormat versus SwiftLint, and the difference is in what each one is allowed to do. SwiftFormat rewrites your source. It can insert implicit self, drop redundant parentheses and adjust whitespace, and the README presents that rewriting as the point of the tool. SwiftLint, as commonly used, reports problems and leaves the edit to you.

That difference in approach has practical consequences. A formatter can be run automatically as a build phase or a pre-commit hook, because the output is the input plus a style change; the README documents both of those integrations. A reporting linter is better suited to a CI gate where a human decides. If you want the style problem to disappear without anyone reading a report, SwiftFormat is the tool. If you want a list of things a human should look at, it is the wrong one.

The two can coexist, and the integration list in the README (build phase, pre-commit hook, GitHub Actions, Danger) is the same plumbing a linter would use. Running both means two tools writing to the same review, so decide which one owns which class of complaint before you wire either into CI.

Maintenance, licence and upgrade cost

The repository is not archived, and its last push was on 2026-09-21. Recent releases on the page are 0.63.0 on 2026-08-30, 0.62.1 on 2026-07-07 and 0.62.0 on 2026-07-06. The version numbers are below 1.0, which is worth reading literally: the project has not declared a stable API, and a formatter's output is its API. A minor-version upgrade can change what a rule does, and that change appears as a diff in your repository rather than as a compile error.

Upgrade cost is therefore concentrated in the config file, not the binary. Pinning a version is the mitigation the README itself demonstrates: the Nix example pins `swiftformat_0_58_7` and tells you to replace it with the version you want, and the `Package.swift` binary target example pins a release URL and a checksum. Both are ways of deciding when the formatter's behaviour changes, rather than discovering it in a pull request.

The licence is MIT, per the repository and the README badge. That is a permissive licence, which in practice means the usual obligations around retaining the copyright and licence text apply when you redistribute the tool. This is a description of the licence identifier, not legal advice; if you are redistributing the binary inside a product, read LICENSE.md in the repository and talk to whoever handles licensing on your side.

Editorial conclusion

Adopt SwiftFormat if you have a Swift codebase with more than one contributor and no agreed style, and you want that style enforced by a tool rather than by review comments. Do not adopt it expecting a linter: it reports violations only under --lint, and it has no notion of a bug. Before you run it across a repository, verify three things: that the --swiftversion you pass matches what your code actually compiles against, that you have read the rules documentation at swiftformat.info/rules for the rules you enable, and that your first run is a --dryrun over a branch you can throw away.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. nicklockwood/SwiftFormat on GitHub
4. README
5. Releases