Using Swift Extensions The “Wrong” Way

When others look at my Swift code, they immediately ask why I use so many extensions. Here is a comment I got the other day from another article I wrote:


The main reason I use extensions is for readability. Here are the use-cases where I LOVE to use extensions, even though that’s “not what extensions are made for”.

Private Helper Functions

In Objective-C, we had .h and .m files. As annoying as it was to maintain both (and have double the files in the project!), it was nice to glance at the .h file and immediately see the external API of the class, while the internals were kept private in the .m file. In Swift, we have only one file.

So to make it easy to glance and see the public functionality of the class – the functions that can be accessed externally vs the private stuff, I keep the private internals in a private extension like this for example:

Note that in the above example, the logic for how the attributed string is calculated is super complicated. If it was in the main section of the struct, I wouldn’t be able to easily glance at it and know which parts are important (that would belong in the .h file in Objective-C!). This makes my code cleaner.

Having a long extension like this is also a good starting point for refactoring out the logic into it’s own struct potentially, especially if this attributed string is needed elsewhere in the code! But putting it in a private extension is a good starting point while writing the code.


The actual reason I initially started using extensions in Swift was because when Swift first came out, there was no way to make pragma mark comments! Yes, that was the first thing I wanted to do when Swift came out! Pragma marks were the way I separated out my code in Objective-C, and as soon as I started writing Swift, I needed it.

So I went to the WWDC Swift Labs and asked how to do pragma marks in Swift. The engineer I talked to suggested I use extensions instead. I started doing this, and absolutely LOVED it.

While pragma marks (//MARK in Swift) is great, it’s easy to miss adding a MARK to a new code section, especially on a team with different coding styles, and end up with functions that don’t belong in the MARK group or are out of place. So if there are a group of functions that belong together, I tend to put them into an extension.

I usually have an extensions to group all the initial styling methods for a ViewController or AppDelegate:

Or to group all notification logic together:

Protocol Conformance

This is a special case of grouping. I like to put all functions that conform to a protocol together into an extension. I used to do this with a pragma mark in Objective-C, but I like the harder separation and readability of the extensions:

This also works great for separating out UITableViewDataSource vs UITableViewDelegate:


This is something I liked when using Core Data in Objective-C. Since the models were generated by Xcode when changed, the functions / anything extra needed to be put into an extension / category.

I try to use structs in Swift as much as possible, but I still like using extensions to separate out the Model attributes vs calculations based on the attributes. It makes the model code a lot more readable for me.


While this might not be “traditional”, the super simple use of extensions in Swift can make code super nice and readable.

Enjoy the article? Join over 20,000+ Swift developers and enthusiasts who get my weekly updates.