How to avoid chaos in a collaborative Xcode project

How many times has it happened to you that you were very comfortable coding with your own style, in your own way but, suddenly, your team grew from just you, a single developer, becoming a team composed by five others?

Not everyone will be comfortable with the way that you organize your code and your style, because each of us has his own approach. Can you imagine a team of six developers coding without sharing any guidelines? It easily gets out of control and is likely to become really chaotic! And that’s the special situation when SwiftLint comes to the rescue.

What’s it all about?

Before digging deeper, let’s go over a few concepts.

• What is a linter/lint?

A linter — or lint — refers to a tool that analyzes source code to find programming or stylistic errors, bugs, and suspicious constructs.

• What is SwiftLint?

SwiftLint is a linting tool to enforce Swift style and conventions, loosely based on GitHub’s Swift Style Guide. It hooks into Clang and SourceKit to use the AST representation of your source files looking for more accurate results.

Installation

You have many ways to install SwiftLint on your mac, but the most common and simple one is by using Brew:

brew install swiftlint

You can check the documentation if you are not familiarized with Homebrew and you want to install it through Cocoapods, Mint or use the pre-built package.

Xcode and project configuration

Now that we accomplished the installation, it’s necessary to configure our project to run SwiftLint. In order to allow Xcode to run swiftlint command, you have to create a run script for the target.

You will have to select the project in Xcode, select the correspondent target, go to the Build Phases tab, click on the + button and select New Run Script Phase.

Then paste the following code.

if which swiftlint >/dev/null; then
   swiftlint
else
   echo “Warning: SwiftLint is not installed, download it from https://github.com/realm/SwiftLint"
fi

Your build phase should end looking like this.

Note: you may rename the default build phase name. In my case, I named it ‘Swiftlint’.

The build phase should look like this.

Now you can build (⌘ + B) your project. Once it’s done, some errors or warnings will be shown in your project, as you can see below.

Warning!

Let me tell you in advance, that in case you use any dependency manager, you will also have errors from the 3rd party libraries we integrated. And this is when you might think “Hell, I don’t need this. I can live without a linter”, but don’t lose your faith just yet!

You can create a configuration file in order to customize which rules you want to run, which ones you don’t and also set special parameters for any specific rule. So let’s configure them.

First of all, you need to be at the same folder level of your Xcode project.

.swiftlint.yml

You can use vi or touch or any other text editor you want. Then, this will create an empty configuration file for our rules.

Now, you might be wondering what to put in this file. Let me help you with that, by just providing you with a reference file.

Let me explain you a bit about what you just have seen.

• disabled_rules: This key is very self-explanatory, it excludes every rule in our code that we don’t want Xcode to evaluate.
• opt_in_rules: SwiftLint has a set of default rules, that runs without configuring anything. But it also has some optional rules, that, by the way, are very interesting, but you have to specify on this file that you want those rules to run on every build command.
• excluded: This key excludes the specified folders, files, etc. But maybe the thing that you may want here is the dependency manager, just because almost all the dependencies aren’t aligned with SwiftLint rules.
• The other lines just configure particular rules. For example the force_cast one is supposed to trigger a warning instead of an error, or the identifier_name key that works for the min and max values.

SwiftLint hacks

Sometimes the next magic command will be your best friend. It will help you a lot to avoid repetitive fixing fool errors like trailing or sorting the imports.

swiftlint autocorrect

Xcode text editing help

While using Xcode as your IDE, you have the possibility to configure it to help you.

These two options will help you a lot to identify where your line length is ( line_length) and to trim the trailing whitespace (trailing_whitespace) every time you press return and lose the line focus.

About SwiftLint

SwiftLint is maintained and funded by Realm Inc. But its code is open source, you can contribute to the project with new rules or bug fixing if you want. You can learn more about SwiftLint by taking a look at this video.

SwiftLint and CI integration

SwiftLint has an integration with Fastlane, another great tool for iOS development and for automating all your deployment processes. But if you have a CI server and no Fastlane configured, you can also integrate SwiftLint if your CI server happens to be Jenkins, Travis or Circle.

Conclusion

In my opinion, SwiftLint is a great tool for iOS/macOS development, that really helps us to keep our codebase very clean, maintainable and aligned with both our team and the Swift Community.

SwiftLint enforces us to avoid some bad practices like performing a force cast or force unwrapping. It also leads us to learn some language features like it happened in my case with the for where clause.

Triggering example:

For Where Clause

Non triggering example:

You can also check all the rulesets that SwiftLint applies here.