How do I get an HTML report from SwiftLint?

`swiftlint lint --reporter html > swiftlint.html`. It writes a single self-contained file with every violation, its rule, severity and location — no assets folder, nothing to zip.

Can I publish it from a CI job?

Yes. SwiftLint exits non-zero when it finds errors, so write the report, then publish with `|| true` around the lint step — the run with violations is the one worth a link.

Does this work in an Xcode Cloud or Bitrise job?

Anywhere curl runs. The report is one HTML file and the publish is one PATCH with a Bearer token, so it drops into any CI that can run a shell script.

Why not just read the Xcode warnings?

Because the person who decides whether `type_body_length` should be raised is often reviewing a PR on a laptop with no checkout. A URL reaches them; an Xcode warning does not.

Can teammates comment on a specific rule?

Yes. Threads anchor to the rendered content, so "we're disabling this rule, here's why" stays on the rule rather than in a channel nobody can search six months later.

Share a SwiftLint HTML report

SwiftLint has the best possible integration point and the worst possible audience problem. Warnings appear in Xcode, right where the code is — which means they reach exactly the people who already have the project open, and nobody else.

The conversations that actually change a lint setup happen elsewhere: a PR review, a team channel, a call about whether the 400-line view controller rule is helping. None of those have Xcode open.

One file, one command

swiftlint lint --reporter html > swiftlint.html

That is a single self-contained document — the violation table with file, line, rule identifier, severity and message. No assets directory, nothing to zip, nothing that breaks when it moves.

Other reporters are worth knowing for other purposes:

--reporter json for tooling.
--reporter sarif if you want the findings in a code-scanning UI — see sharing a SARIF report.
--reporter html when the reader is a person.

Publish it

Drag swiftlint.html into Comma, or publish from CI and keep one permanent link:

swiftlint lint --reporter html > swiftlint.html || true

curl -fsS -X PATCH "https://commareports.com/api/v1/reports/$REPORT_ID" \
  -H "Authorization: Bearer $COMMA_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d "$(jq -n --rawfile html swiftlint.html \
        --arg t "SwiftLint — $CI_COMMIT_SHORT_SHA" '{title: $t, html: $html}')"

|| true because SwiftLint exits non-zero on error-severity violations, and that run is precisely the one someone needs to look at. See the API reference and publishing from CI.

The argument is about the config, not the code

Every Swift team has the same recurring debate — line_length, function_body_length, force_cast, whether identifier_name should allow id. It recurs because the evidence and the discussion are never in the same place: the evidence is in a build log, and the discussion is in Slack.

Publish the report, and the discussion can happen on the evidence. A thread on the 84 line_length violations — "most of these are SwiftUI modifier chains, raising to 140" — is a decision with its justification attached, and it stays anchored across republishes. See commenting on HTML.

A revision per run

PATCH one saved report id from every CI run and the URL never changes while the content tracks main. Each publish appends a revision, so "did that rule change actually reduce anything?" is answered by opening two runs rather than by trusting a memory.

Who can see it

Per report: private, your team, anyone signed in at your domain, or anyone with the link. A lint report names files and functions — team access is the usual setting. See sharing & access control.

Limits

Entry HTML: 5 MB. A very large violation table can approach that; scope the run with --path or included: in .swiftlint.yml.
Assets: 25 MB per file, 250 MB and 500 files total.
60 requests/minute per token.

Try it

Comma is free — unlimited reports, unlimited commenters, unlimited revision history.

Publish a lint report →