We all talk to follow Swift Style & Conventions, and we have an impactful tool available for us — SwiftLint. I’ll not talk about more here on how to setup and use this tool in our project. For all these details you can go through their GitHub Page and refer.

I’ll focus here mainly on —

  • Enforce that all default set of SwiftLint rules are marked as errors
  • Adding own custom rules to streamline best practices as per defined organisation level structure
  • Integration to CI

Let’s start with first thing first.

SwiftLint has added various rules, as default, in their own bundle. They have marked few of them as warning, while few are marked as errors. To get list of all — Refer Here

As per me, Swift guidelines must be followed, there is no scope of warnings. If something is not correct then its simply needs to be corrected. For example, SwiftLint has marked “force_unwrapping” as warning in their ruleset while its the most obvious reason of CRASH at run time. It must be corrected. So, here is the script which you can add in your Build Phase, which will mark all warnings as error —

We can customise default rule set as per our need in YML file.

Next comes the most beautiful part — Custom Rules

We can add any rule to SwiftLint as per our needs in YML file which will be enforced at build time for the developers. You can refer Custom Rules to get more details. In this story I am going to help you with some rules which I’ve added in our projects and you can use as is OR modify as per your needs.

  • TODO — If there is a TODO declaration in project then that must have git/JIRA link attached to it
  • Multiple Empty Lines — Code File must not have multiple empty lines (It supports Auto Correct)
  • Weak Delegate / DataSource — To prevent retain cycles, delegates & datasources must be declared as weak variables
  • Fatal Errors — Code must not have reference to fatal error calls
  • SwiftLint File Disable — Developers should not be allowed to disable any Swift File lint
  • Try inside Do/Catch — try call must always be in do/catch block
  • Weak Self in Closures — To prevent retain cycle, Closure refering to self, must declare them as weak
  • String Literal — Strings should always be referred from Localization File
  • Protocol Conformance in Extension — Protocol conformance should be declared in separate extensions in the same file
  • UIKit in Model / ViewModel / DataSource — There should be no import of UIKit in these files
  • Public UIModel — UIModel classes must be public
  • Non-Public DataModel & DataSource — DataModel & DataSource must be non-public

Integration with CI — GitLab

We can integrate SwiftLint in GitLab Pipeline to make sure that all rules are enforced and corrected in each git push. Refer Continuous Integration — GitLab — iOS — Part 2 for more details on this.

I design modular development & templates for better coding practices, robustness, scaling & reusability for development inline with automation.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store