A useful suggestion explains the reasoning.
Enable JavaScript to explore numbered annotations. The rule examples below remain readable without it.
SWIFT CODE. SHARED STANDARDS.Clarity in
Clarity in
every line.
Less time debating style. More time building something great. Bring clear, configurable conventions to your Swift projects.
THE INTERACTIVE REVIEWSee the issue.
See the issue.
Understand the improvement.
Three real-world scenarios. Seven annotated findings. Follow each suggestion from the exact code location to a considered revision.
Original codeSWIFT
if messages.count == 0 { }
// Suggestion: messages.isEmptyProblem expressionSuggested change
Interactive teaching examples, not live analysis. Suggested revisions may change error handling; review them against your application requirements.
Meet your next code review.
Explore a convention, understand the feedback, and see a better approach.
Prefer isEmpty when checking a collection for emptiness.
BEFORE
if items.count == 0 { }AFTER / SUGGESTION
if items.isEmpty { }READ THE CHANGE
Prefer isEmpty.
Opt-in rule: enable empty_count.
Read the official rule ↗One workflow. A shared language.
Write
Focus on valid, compilable Swift code.
Check
Run swiftlint lint locally for actionable feedback.
Integrate
Add checks to your Xcode or Swift Package build.
Share
Commit your configuration so the team shares conventions.
Your project. Your conventions.
Start with a small, deliberate configuration. Expand it as your team gets comfortable.
opt_in_rules: - empty_count excluded: - Pods force_cast: warning
From installation to integration.
Install on macOS with Homebrew.
brew install swiftlint swiftlint lintOfficial guide ↗
Turn a rule into a team habit.
Start with intent
Choose a few rules your team can explain. For new projects, agree on the initial configuration before the first large feature lands.
opt_in_rules: - empty_count - empty_string - explicit_init excluded: - Pods
These are the opt-in rules used in our examples. Commit the configuration alongside your source.
Separate fixes from decisions
Check the project, apply supported corrections, then inspect the diff. Keep behavior-changing edits small enough to review carefully.
swiftlint lint swiftlint --fix git diff
A conditional cast needs an intentional failure path. A style tool cannot decide your product behavior.
Keep adoption manageable
For a mature codebase, introduce conventions in stages. Review exclusions and the official baseline workflow rather than mixing a repository-wide cleanup with feature work.
- Choose and document a shared rule set.
- Use the same tool version locally and in CI.
- Review rule changes like code changes.
A few practical answers.
Does SwiftLint fix every issue?
No. Only supported corrections can be applied automatically. Review changes and use human judgment for semantic changes.
Can an existing project adopt it gradually?
Yes. Start with a focused rule set and exclusions. Explore the official baseline feature to manage existing violations.
How do I choose rules?
Review the rule directory, distinguish default and opt-in rules, and agree on conventions with your team.
Where should checks run?
Run locally for fast feedback, then integrate with build tooling. SwiftLint expects valid, compilable Swift source.