Linting and formatting Swift code in our apps

In the iOS community at Glovo, we care about conventions, code style and standards. Apart from our guidelines (such as Swift style and reactive programming), we take advantage of tools to lint and format our code.

Why would we want to use such tools?

Well, each engineer has their preferred style to format code, but when there are so many people collaborating in a project (we are more than 30 iOS engineers), it’s important to have a common style, following industry standards and our guidelines. Enforcing such conventions and actually manually formatting the code can also be a very tedious task, so why not automate it? By using these tools, we focus on what really matters.

But what’s the difference between a linter and a formatter?

A linter will tell you what’s wrong with your code. It enforces conventions and code style. It performs static analysis, looking for violations such as not adhering to conventions, errors and potential problems (code smells). It can also provide some level of formatting, but not as much as a formatter can do.

A formatter can possibly also offer linting capabilities, but its main goal is to fix the code. In summary, the linter will report style violations and code smells, and the formatter will actually fix those.

We have chosen the following tools: SwiftLint and SwiftFormat.

In which steps do we perform linting and formatting?

We run SwiftLint directly in Xcode: autocorrect as a pre-action and lint as a build phase. As for SwiftFormat, we run it as a git pre commit hook.

Our current SwiftLint config file looks like this:

Our current SwiftFormat config file:

All rules are agreed within our iOS community and are also present in our guidelines.