How to use SwiftLint with Xcode to enforce Swift style and conventions?

SwiftLint is a tool to enforce Swift style and conventions. Keeping a codebase consistent and maintainable in a project with a team of developers sometimes may be very hard, different conventions and styles, plus different levels of experience with the language across developers may result in most of the times in an application very difficult to debug and mostly very hard to understand for new developer joining the team.

1. Installation

Simplest way to install SwiftLint is by downloading SwiftLint.pkg from the latest GitHub release and running it. During the installation you may see this alert -

In this case you need to grant an exception for a SwiftLint by clicking the "Open Anyway" button in the General pane of Security & Privacy preferences. This button is available for about an hour after you try to open the app. To open this pane, open System Preferences and click Security & Privacy.

Now you just need to follow the installation instructions. You can also install SwiftLint using Homebrew by running this command:

brew install swiftlint

2. Integrate SwiftLint with Xcode

In order to integrate SwiftLint with Xcode project target to get warnings and errors displayed in the Xcode IDE, you just need to add a new "Run Script Phase" with following script -

if which swiftlint >/dev/null; then
  echo "warning: SwiftLint not installed, download from"

If you don't know how to add a "Run Script Phase" in your project target, here an image for your reference -

3. Test and Configure

In order to test the integration of SwiftLint with your Xcode project target, you just need to build your application and you should have a lot of errors and warnings, mostly if your project has pods installed.

Don't worry, the cool thing is that we can configure what rules to check or not when using Swiftlint. To configure it, all you have to do is create a new file inside your project folder named .swiftlint.yml. Here the general .swiftlint.yml file, which I recommend you to use in your project.

- trailing_whitespace

- empty_count
- empty_string

- Carthage
- Pods
- SwiftLint/Common/3rdPartyLib

    warning: 150
    error: 200
    ignores_function_declarations: true
    ignores_comments: true
    ignores_urls: true

    warning: 300
    error: 500

    warning: 6
    error: 8

    warning: 300
    error: 500

    warning: 1000
    error: 1500
    ignore_comment_only_lines: true

    warning: 15
    error: 25

reporter: "xcode"

Now, Save configuration file and build, you will see that the number of warnings and errors are now so much lower. I recommend you to go to the Swiftlint rules file in their repository and see all of them. Or you can run swiftlint rules command to see all the rules. Also, this will validate your custom .swiftlint.yml file if you run this command in your project directory where .swiftlint.yml file available.

4. Hide Pod Warnings

You can hide Pod warnings from your Xcode Project by adding inhibit_all_warnings! in your Podfile for all 3rd party dependencies or :inhibit_warnings => true for specific dependency.

platform :ios

# ignore all warnings from all dependencies

# ignore warnings from a specific dependency
pod 'FBSDKCoreKit', :inhibit_warnings => true

Then you need to execute pod install.

5. Auto Correct

A cool thing about Swiftlint is that it also can automatically correct certain violations by running the following command on the terminal -

swiftlint autocorrect

Also, Before using the autocorrection feature, Files on disk are overwritten with a corrected version. So, make sure to have backups of these files before running swiftlint autocorrect, otherwise some data may be lost.

6. Configuration Parameters

The following parameters can be configured:

disabled_rules: Disable rules from the default enabled set.
opt_in_rules: Enable rules not from the default set.
whitelist_rules: Acts as a whitelist, only the rules specified in this list will be enabled. Can not be specified alongside disabled_rules or opt_in_rules.

disabled_rules: # rule identifiers to exclude from running
  - colon
  - comma
  - control_statement
opt_in_rules: # some rules are only opt-in
  - empty_count
  # Find all the available rules by running:
  # swiftlint rules
included: # paths to include during linting. `--path` is ignored if present.
  - Source
excluded: # paths to ignore during linting. Takes precedence over `included`.
  - Carthage
  - Pods
  - Source/ExcludedFolder
  - Source/ExcludedFile.swift

# configurable rules can be customized from this configuration file
# binary rules can set their severity level
force_cast: warning # implicitly
  severity: warning # explicitly
# rules that have both warning and error levels, can set just the warning level
# implicitly
line_length: 110
# they can set both implicitly with an array
  - 300 # warning
  - 400 # error
# or they can set both explicitly
  warning: 500
  error: 1200
# naming rules can set warnings/errors for min_length and max_length
# additionally they can set excluded names
  min_length: 4 # only warning
  max_length: # warning and error
    warning: 40
    error: 50
  excluded: iPhone # excluded via string
  min_length: # only min_length
    error: 4 # only error
  excluded: # excluded via string array
    - id
    - URL
    - GlobalAPIKey
reporter: "xcode" # reporter type (xcode, json, csv, checkstyle, junit, html, emoji)

You can also use environment variables in your configuration file, by using ${SOME_VARIABLE} in a string.

7. Watch Your Language!

Here the great presentation by JP Simard -

References -

Related Article