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 14,500+ Swift developers and enthusiasts who get my weekly updates.

  • The Swift core team loves to use extensions for the same reasons 🙂

    This is from the first public stdlib file I could find: The extensions are used purely for grouping. There are plenty more examples where extensions are used for protocol conformance (_e.g._ this set:

  • Dominik Hadl

    I use the extensions in the exact same way and I don’t it’s not how they should be user. IMO it makes the readability a lot better and it’s easier to enforce code guidelines.

  • Apokrupto

    I’m pretty much the same, I get upset that I can’t have a stored private property in the extension

    • Mark Krenek

      Yeah, that’s my issue. I use extensions a fair amount but find that sometimes I need a stored property specific to the extension. What’s the recommendation for that use case? It’s clumsy to have to put that in the main class definition isolated from where it is actually used.

      • Apokrupto

        I haven’t discovered a solution that makes me comfortable. I usually end up putting the property in the class if I own the class, otherwise I’m reduced to calculated properties with good old fashioned objc_setAssociatedObject, which comes with its own baggage.

        • Darius

          In this case, I usually prefer to create a private struct or class, instead of an extension.

  • Artem Gladkov

    Interesting information about dependence of extensions count and project’s build time. I think, worth reading for extension lovers 🙂

    • This is from almost a year ago… do you know if this is still the case?

      • Artem Gladkov

        I found this link in recent conference (middle of March). Speaker used this information in his project and got fantastically positive results.
        slide number 10.
        So I think that this is still actual information.

      • Apokrupto

        I don’t know about Xcode 7.3, but it’s certainly still the case with Xcode 7..2.

        I did some playing around with the various optimisation settings recently and it turned out that removing extensions completely gave me a significant decrease in build time.

        However, keeping extensions and using ‘-O -whole-module-optimised’ resulted in exactly the same time reduction.

        I got greedy and removed extensions and used fast optimisation, but combined they didn’t show any improvement.

  • Joshua Kaden

    Also: If you need to add functionality to an existing Obj-C class, you can extend it in Swift.

  • herbWat

    Thanks for the write up.
    What’s your opinion on using a protocol for the mentioned public API separation?

  • Mark Patterson

    I think it is great to keep code in short logically connected units. These Extensions are a good way to do that.

  • tapok

    Extensions are really great.
    Just one thing. What are you doing when you need to use inheritance? For now methods declared in extensions can not be overriden

  • Vinicius Vendramini

    Are there any reasons for preferring to “use structs as much as possible”? My reflexes always take me to classes before going to structs, but I never really thought about this decision.

  • Michael Peterson

    Wow, I do the exact same things, glad to see I’m not crazy. These uses of extensions just seems natural and are a great way to add some organization to the problem of Massive View Controller.

  • Jakub Petrík

    Not only that extensions helps your code to be more readable and nice but more importantly, they allows to collaborate on the same type without dealing with any conflicts whatsoever. This is the reason I love to use them and I used them a lot. 🙂

  • That is a cool way to organize the code. I have seen this on the Ray wenderlich’s books and I keep doing this. It is really clean and easy to read! Thanks for sharing!

  • Alex

    Hey, nice topic, should I use extension for grouping? I am new in Swift, so all is interesting for me. As Swift Programming Language Guide (2.2) says: “Extensions add new functionality to an existing class, structure, enumeration, or protocol type”

    It looks like it really helps and makes code more readable, but is this a purpose for extension? In my understanding extension should be a part of decoration process, when we what to decorate some object by given object some new functionality. In Objective C, categories is about what extension should be in Swift and Pragma Marks are about grouping. So do we need to use the keyword EXTENSION for grouping? I guess it’s not so clean because of semantic as EXTENSION has to extend, but we use it for purpose GROUP. Any suggestion here?

    Also there is one comment here that seems we can’t override method from extension right? I don’t know as I new but if so in this case we will have different functions in different places. Assuming we have a group (extension) that does for some styling operation and in some case we need a function that should be overridden, then it breaks a grouping logic as we have functions in different places.

    One more it’s just my understanding as I just started learning Swift. There is no best practice suggestion from my side, just question regarding how I understand extension.


  • Mee

    What if protocol requires init() conformance? This breaks “the harder separation and readability” thing as you need to declare required init() in the main class/struct/enum body.

  • Horex Chen

    yeah. It is nice for interfece private property or function. And i just use it for potocol or seperator mass model. And I think extension also can be used for extension of potocol in order to supported default function implement instead of user @objc for opition function.

  • Edinson

    Thanks for this article, I used extensions in the exact same way (Y) … I learned something new “private extensions”

  • Manoj Aher

    The extensions are really good way when it comes to confirming the protocol.
    Makes the code more readable.

    But for properties adding // MARK: makes the code more readable.

    // MARK: Private properties
    private var abc: ABC!
    private var def: DEF!

    // MARK: Public properties
    var ghi: GHI
    var jkl: JKL

    Similar for methods too. This helps the other developer to see only public properties and functions that he can use.

  • Andrey Kadochnikov

    Good article. However, the bad thing with extensions – they don’t support stored properties, so the idea of extracting private internals from public ones along with idea of grouping things are quite defective to me. PS. oh, I’m duplicating others opinions, sorry

  • Prajeet Shrestha

    By the way implementing Delegates and DataSource in extension just seperates the code in different block. While it may improve the readability. It’s still a Massive View Controller in disguise.

    • Alex

      do you mean it’s better to use separate file for these purposes? for example move datasource and delegate to some TableViewControllerExtenstion.swift?

  • thanks for separating out UITableViewDataSource vs UITableViewDelegate……