# Share a SwiftLint HTML Report — One Link, No Xcode

Canonical: https://commareports.com/share-swiftlint-report
Published: 2026-09-14

> SwiftLint's html reporter writes a single self-contained file. Publish it to Comma from CI: a URL per run, comments on the rules worth arguing about, a revision trail.

# 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

```bash
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](/share-sarif-report).
- `--reporter html` when the reader is a person.

## Publish it

Drag `swiftlint.html` into [Comma](https://commareports.com/), or publish from
CI and keep one permanent link:

```bash
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](/docs/api) and [publishing from CI](/docs/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](/comment-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](/docs/sharing).

## 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 →](https://commareports.com/)**

### Related

- [Share a ktlint report](/share-ktlint-report) · [Share an ESLint report](/share-eslint-report)
- [Share an Xcode test report](/share-xcode-test-report) · [Share a DocC archive](/share-docc-archive)
- [Share a detekt report](/share-detekt-report) · [Share a SARIF report](/share-sarif-report)