Swift: How To Name Your Extensions

One of my favorite patterns in iOS programming with Swift is to create multiple extensions throughout my files to keep related methods together. For example, every time my ViewController conforms to a protocol, I keep the protocol methods together in an extension. Same goes for multiple private styling methods or private cell configuration methods in a table view, etc.

The only thing missing from this pattern was that I was unable to name the extensions. Instead, I had to use // MARK: everywhere to keep track of the groupings. I mentioned this to @allonsykraken the other day, and he showed me a simple trick for this – using typealias!

I’m sure you’re now wondering the first thought that popped into my head when I saw this – what about the groupings in the Xcode nav bar?!!! Don’t worry, it’s all there!

Extensions Swift

Let me know what you think about naming your extensions like this in the comments! Would love feedback as I’m still deciding how much I like this vs just using MARK: here.

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

  • IMO this is weak. When you create another view controller and try the same trick you end up with “Invalid redeclaraion of ‘TableViewDataSource’. I think you probably assumed there will be just this one data source in the app or in this example and this is not the case now.

    • I tried it in a diff view controller with the same typealiases and it works. That’s why I made the typealiases private.

    • Either way, you could name them to be more specific: MyViewControllerDataSource. Focusing on the concept here.

  • I personally would not do this. My style is to not write code that is not necessary. It seems to me (correct me if I’m wrong) that you are doing this to get Xcode to list the names of the extensions in the navigation bar. That’s what // MARK: is for, and this is clear to everyone reading your code.

    Declaring a private typealias is an obscure way to obtain the same, but that’s not what type aliases are for. Anyone else reading your code would wonder: what is this for? They are not required for extensions and since these type aliases are never used anywhere, the reader would not find an answer to this question.

    It would be great if Xcode displayed them without any additional line. But since it doesn’t, my preference goes to // MARK:

    • +1

    • Isuru Nanayakkara

      I agree. Sprinkled typealiases seem messy.

    • zjczhjuncai

      I agree.
      private typealias causes more confusion. The more you write, the more chance to get wrong.

    • Yariv

      “// MARK: – ” will show a line, drop the “-” to not have a separator line

    • Rainer Drexler

      Full Acknowledge. Nobody should do that. For me it´s a anti pattern

  • Vjosullivan

    Works less well on extensions like Equatable or Comparable where the == and < functions are defined after rather than inside the extension declaration. When that happens the functions aren't indented in the drop-down, so the hierarchy is less visible. (However, as stand-alone functions they are prefixed with an "f" icon rather than an "m" icon, as above.

  • Really interesting idea, thanks for sharing Natasha. What I’ve found myself doing is having a folder (or group) named ViewController, for example, then within that folder having the main class (or type), then for each extension or range of extensions have additional files named _TableViewDataSource.swift, _TableViewDelegate.swift and so on. I hate having code files that are overly long and being able to collapse and expand groups makes for easy navigation. I can then use // MARK: within the files for even quicker navigation to the subparts.

    • Interesting idea as well. I wouldn’t like having that many files personally and I try to keep my ViewControllers short, so it hasn’t been too much of a problem.

      • Writing a JSON parser is where I first did this because I had a central enum type with Array, Dictionary, String, etc. and I wanted to separate the functionality of each while being able to have a single type.

    • Piotr Tobolski

      Creating separate files for those categories would disallow usage of private properties, methods nad functions in categories

      • Yes, you would be restricted here but for the type of separation I’m thinking of this might well be an advantage. The issue has mainly arisen for me so far, as noted below, where I need a whole variety of functionality in a single type that is internally segregated. This need might change in future if the sophistication of the “where” keyword expands.

  • Kevin Xu

    I still like my // MARK: – UITableViewDataSource above the extension. The different code style / color helps me easily scan the different sections

    • I’ll probably still keep the //MARK: as well, but found this to be an interesting idea to explore.

      • Kevin Xu

        Ditto, love exploring new ideas! One of the handiest usages for typealias for me so far has been aliasing complex completion blocks like typealias SuccessCompletionBlock = (RKObjectRequestOperation!, RKMappingResult!) -> Void

        • +1 to that! I do that all the time.

        • vanylapep

          I always find a problem with this tho. Since you are not giving a parameter name, it’s hard for the person who reads your code know what RKObjectRequestOperation and RKMappingResult are for. In your example, it could be self explanatory, but when you have Bool, it’s hard to guess what it represent. Or am I not understanding this correctly?

          • Kevin Xu

            That’s true, ideally one can cmd+click the alias into it’s actual definition that maybe supplies a comment explaining things

          • vanylapep

            That could work.

  • I prefer // MARK: style , typealias looks interesting , but as chinese words goes, “然并卵!”

  • Bob Godwin

    Natasha I really love your posts but this last one is not convincing.. [typealias] like the word implies should be used to expose a generic type for public use and not for [//MARK: – ] We are still looking for the correct design patterns for swift and I believe you can do better..:) However typealias is very interesting and I believe every one should read some thing about it. For example I was able to use it expose an NSManagedObject attributes… Please keep writing…

    • Rainer D.

      Full Acknowledge

  • Chlebta kaouach

    Please someone explain the advantage of using extension ? why using them ?

    • Edias

      On this specific case I can’t see any…

    • Tony Dunkin Hung

      I think it keeps the file clean and makes the extension more readable. Like if you have a extension on a viewController with similar functions, it would be nice to put a name to it. If other developer comes onto the project, they won’t have to read all the functions in that extension to understand what it does, you can just read the name of the extension

  • Edias

    Hi Natasha,

    Sorry for the question but I’m just curious…

    Which benefits you see breaking down your TableViewDelegate and TableViewDataSource in separated extensions?

  • Stanislav