SwiftLint: enforcing Swift style with rules, plugins and autocorrect

What SwiftLint enforces and who ends up using it

SwiftLint is a command-line static analysis tool that checks Swift source against a set of style rules. The README describes it as loosely based on the archived GitHub Swift Style Guide, with rules drawn from guides such as Kodeco's Swift Style Guide. That framing matters: this is not a general-purpose bug finder. It is a convention enforcer, and the conventions are the ones the Swift community broadly accepts rather than a house style invented by the maintainers.

The audience is Swift teams that want style review to stop being a matter of opinion in pull requests. An iOS app with several contributors, a framework with a public API surface, or a codebase that has drifted across years of contributors all fit. A solo developer writing a small script will get less from it, because the value comes from consistency across people and time.

The rules are predominantly based on SwiftSyntax, the parser library from swiftlang. A subset still hooks into Clang and SourceKit to reach type information, which is the detail that separates SwiftLint from a text-based linter. A rule that needs to know the type of an expression cannot be written as a regular expression over lines.

How the rules are built and why type-aware rules behave differently

The architecture follows from that split. Most rules parse Swift into a syntax tree and inspect nodes, so they see structure rather than text: a closure, a function body, a declaration. That is why SwiftLint can flag things that look fine to a line-based tool and ignore things that a naive pattern would flag.

The remaining rules call into Clang and SourceKit for type information. Those rules are more expensive and more fragile in practice, because they depend on the compiler infrastructure being present and on the code being in a state the compiler can reason about. This is the same reason the README insists SwiftLint should analyze valid, compilable source. If the file does not parse or the types do not resolve, a type-aware rule has nothing reliable to work from.

The practical consequence is that two rules in the same configuration file can have very different failure modes. A syntax rule either matches or it does not. A type-aware rule can produce odd results on a half-finished branch. When a lint run gives a result that looks wrong, the first question is which category the rule falls into.

Installing SwiftLint and running a first lint pass

The README lists several installation routes, and the choice depends on how your project already manages dependencies. Homebrew is the shortest path on a Mac:

brew install swiftlint

After that, running `swiftlint` in a directory lints the Swift files it finds. CocoaPods users add a line to the Podfile and invoke the binary from the Pods directory in a Script Build Phase:

pod 'SwiftLint'

The README notes that the CocoaPods route installs the binaries, their dependencies and the Swift binary library distribution into `Pods/`, and that checking that directory into source control is discouraged. It also points out that CocoaPods allows pinning to a specific version, which Homebrew does not.

Mint offers another pinned route:

mint install realm/SwiftLint

For Swift Package Manager, the README recommends consuming the plugins from the dedicated SwiftLintPlugins repository rather than from the SwiftLint repository itself, and says the two are kept in sync so functionality is the same. The package declaration looks like this, with `<version>` replaced by the minimum or exact version you want:

.package(url: "https://github.com/SimplyDanny/SwiftLintPlugins", from: "<version>")

Bazel users can run it from the workspace root once the module dependency is in place:

bazel run -c opt @SwiftLint//:swiftlint

There is also a pre-built `SwiftLint.pkg` on the releases page, and a from-source path that requires Bazel and a recent Swift toolchain on the PATH, followed by `make install`. The repository ships a Dockerfile that builds the command-line tool on a Swift base image and copies it into an Ubuntu runtime image with libcurl and libxml2 installed, so a container-based lint step is possible without a local toolchain.

Whichever route you take, the first real use is the same: run the linter over a target and read the output before you change any configuration.

The compilable-source constraint is the limitation that bites first

The README carries an explicit warning that running SwiftLint before compiling, to fail a build early on violations, is not the intended order of operations. SwiftLint is designed to analyze valid source code that compiles, and the README states that non-compiling code can very easily lead to unexpected and confusing results, especially when running with `--fix` or `--autocorrect`.

That is a real constraint, not a disclaimer. Autocorrect rewrites source based on what the parser understood. If the parser is working from code that does not compile, the rewrite is built on a shaky reading of the file. A team that wires SwiftLint into a build phase ahead of compilation is using it against its design.

The second limitation is scope. SwiftLint checks conventions. It does not replace tests, and it does not catch logic errors. A codebase with perfect lint output can still be wrong. Teams that treat a clean lint run as a quality signal are reading more into the tool than it claims.

The third is configuration drift. Every rule that a team disables is a decision that has to live somewhere, and the README's setup section is where that conversation starts rather than ends.

SwiftLint and SwiftFormat solve overlapping but different problems

The comparison people search for is SwiftLint versus SwiftFormat, and the difference is in what each one is for. SwiftLint is a linter: it reports violations of style and convention rules, and it can autocorrect some of them. SwiftFormat is a formatter: it rewrites code into a canonical layout.

In practice the two overlap in the middle. SwiftLint's `--fix` and `--autocorrect` modes do change formatting, and SwiftFormat's rules can look like lint rules when they are reported rather than applied. The distinction that holds is intent. If you want a report of what is wrong and a policy you can tune rule by rule, that is SwiftLint's shape. If you want the file rewritten to a layout and no debate about it, that is a formatter's shape.

Many Swift projects run both, with the formatter handling layout and the linter handling the conventions a formatter has no opinion about. That combination is not contradictory, but it does require deciding which tool owns which rule so the two do not fight over the same line.

Maintenance, releases and what the MIT licence means here

SwiftLint is not archived, and the last push to the default branch was on 2026-09-20. The release cadence visible in the recent history is roughly every one to two months: 0.65.1 on 2026-08-21, 0.65.0 on 2026-06-27, and 0.64.1 on 2026-06-23. Release notes exist per version, and the CHANGELOG.md file sits at the repository root.

The upgrade cost is not uniform across installation methods. CocoaPods and Mint can pin to a specific version, which means an upgrade is a deliberate edit. Homebrew installs the latest release, so a `brew upgrade` can move you forward without a code change on your side. Bazel pins through the version in the module dependency. That spread is worth knowing before you pick a route, because the method you choose determines how much control you have over when the rules change under you.

The licence is MIT. That is permissive: it allows use, modification and redistribution with the licence and copyright notice retained. It is not legal advice, and if you redistribute SwiftLint inside a product you should read the LICENSE file at the repository root rather than take a summary from an article. The Dockerfile also carries an MIT label in its image metadata, which is consistent with the repository licence.

Editorial conclusion

Adopt SwiftLint if your team wants enforceable, configurable Swift style checks and you already have code that compiles. Do not adopt it as a substitute for a formatter, and do not run it on a broken build: the README warns that non-compiling code can produce unexpected and confusing results, especially with --fix or --autocorrect. Before rolling it out, verify which rules the default configuration enables for your project and check whether any of them need type information through Clang or SourceKit, because those rules behave differently from the syntax-only ones. Start by running swiftlint lint in a single target and reading the .swiftlint.yml reference before you widen it.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. realm/SwiftLint on GitHub
5. Releases