Over the last few months, we have been working hard on our very own Swift style guide, based on our experiences writing Swift code. Now, we are proud to publish the result of this initiative: The Prolific Interactive Swift Style Guide.

The Process

When we started writing this guide, we knew the last thing we wanted was to generate a style guide in a void. How could we vet which Swift styles were good, and which were bad, if we didn’t have a good baseline for those decisions? As a result, we made sure to base our style guide off three important factors.

  1. All iOS engineers at Prolific take a code test during the interview process where they put together a small app. For transitioning to Swift, we required all iOS engineers to retake this same code test using only Swift this time and with no guidance of style or requirements. This was incredibly important in our development of the style guide. We found recurring questions and problems people were having in nearly every project, and we used those pain points as a skeleton for what should be addressed in our style guide.
  2. Next, we formed a small committee of project leads who were using Swift in production-level applications to debate the merits and validity of each point. We made sure to test and research each item in order to make sure we were making a decision that allowed us to write clean, consistent code.
  3. Finally, we used the community and the Swift development team for feedback on each point to make sure that we were making strong and valid choices. We also used the open-source Swift library as a resource to see what the Swift development team had to say on specific topics.

Guiding Principles

We stuck to a few important guiding principles when considering each rule that we added to the style guide:

There are certainly gaps in our style guide, but many of them are on purpose. In many cases, we did not have a clear understanding of what the implications of making a rule would be. In these instances we decided it would be better to omit the rule rather than commit to one that ultimately led to cascading problems down the line. There are other gaps we may have missed, and we welcome your help by contributing!


We have open-sourced our style guide in order to contribute to the community discussion on Swift style. But we also understand that our style guide is not perfect, and with the language constantly evolving, we need to keep evolving as well. As such, we encourage any and all developers to contribute to our style guide in any way they want. There are two ways you can join in the discussion:

Going Forward

We’re very proud of the work we have put together and even more excited about the prospect of continuing to expand and revise our styles. There is still work to be done, but we believe we have compiled a very strong starting point for styles in Swift that we can use going forward.

Share Button