Using Swift Extensions The “Wrong” Way

Posted on March 29th, 2016

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:

Comment

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:

// it's easy to glance and see which parts of this struct are
// supposed to be used externally
struct TodoItemViewModel {    
    let item: TodoItem
    let indexPath: NSIndexPath
    
    var delegate: ImageWithTextCellDelegate {
        return TodoItemDelegate(item: item)
    }
    
    var attributedText: NSAttributedString {
        // the itemContent logic is in the private extension
        // keeping this code clean and easy to glance at
        return itemContent
    }
}


// keeps all this internal logic out of the public-facing API of this struct
// MARK: Private Attributed Text Builder Helper Methods
private extension TodoItemViewModel {
    
    static var spaceBetweenInlineImages: NSAttributedString {
        return NSAttributedString(string: "   ")
    }
    
    var itemContent: NSAttributedString {
        let text = NSMutableAttributedString(string: item.content, attributes: [NSFontAttributeName : SmoresFont.regularFontOfSize(17.0)])
        
        if let dueDate = item.dueDate {
            appendDueDate(dueDate, toText: text)
        }
        
        for assignee in item.assignees {
            appendAvatar(ofUser: assignee, toText: text)
        }
        
        return text
    }
    
    func appendDueDate(dueDate: NSDate, toText text: NSMutableAttributedString) {
        
        if let calendarView = CalendarIconView.viewFromNib() {
            calendarView.configure(withDate: dueDate)
            
            if let calendarImage = UIImage.imageFromView(calendarView) {
                appendImage(calendarImage, toText: text)
            }
        }
    }
    
    func appendAvatar(ofUser user: User, toText text: NSMutableAttributedString) {
        if let avatarImage = user.avatar {
            appendImage(avatarImage, toText: text)
        } else {
            appendDefaultAvatar(ofUser: user, toText: text)
            downloadAvatarImage(forResource: user.avatarResource)
        }
    }
    
    func downloadAvatarImage(forResource resource: Resource?) {
        if let resource = resource {
            KingfisherManager.sharedManager.retrieveImageWithResource(resource,
                optionsInfo: nil,
                progressBlock: nil)
                { image, error, cacheType, imageURL in
                    if let _ = image {
                        dispatch_async(dispatch_get_main_queue()) {
                            NSNotificationCenter.defaultCenter().postNotificationName(TodoItemViewModel.viewModelViewUpdatedNotification, object: self.indexPath)
                        }
                    }
            }
        }
    }
    
    func appendDefaultAvatar(ofUser user: User, toText text: NSMutableAttributedString) {
        if let defaultAvatar = user.defaultAvatar {
            appendImage(defaultAvatar, toText: text)
        }
    }
    
    func appendImage(image: UIImage, toText text: NSMutableAttributedString) {
        text.appendAttributedString(TodoItemViewModel.spaceBetweenInlineImages)
        let attachment = NSTextAttachment()
        attachment.image = image
        let yOffsetForImage = -7.0 as CGFloat
        attachment.bounds = CGRectMake(0.0, yOffsetForImage, image.size.width, image.size.height)
        let imageString = NSAttributedString(attachment: attachment)
        text.appendAttributedString(imageString)
    }
}

// it's easy to glance and see which parts of this struct are

// supposed to be used externally

struct TodoItemViewModel {

let item: TodoItem

let indexPath: NSIndexPath

var delegate: ImageWithTextCellDelegate {

return TodoItemDelegate(item: item)

}

var attributedText: NSAttributedString {

// the itemContent logic is in the private extension

// keeping this code clean and easy to glance at

return itemContent

}

// keeps all this internal logic out of the public-facing API of this struct

// MARK: Private Attributed Text Builder Helper Methods

private extension TodoItemViewModel {

static var spaceBetweenInlineImages: NSAttributedString {

return NSAttributedString(string: " ")

}

var itemContent: NSAttributedString {

let text = NSMutableAttributedString(string: item.content, attributes: [NSFontAttributeName : SmoresFont.regularFontOfSize(17.0)])

if let dueDate = item.dueDate {

appendDueDate(dueDate, toText: text)

}

for assignee in item.assignees {

appendAvatar(ofUser: assignee, toText: text)

}

return text

}

func appendDueDate(dueDate: NSDate, toText text: NSMutableAttributedString) {

if let calendarView = CalendarIconView.viewFromNib() {

calendarView.configure(withDate: dueDate)

if let calendarImage = UIImage.imageFromView(calendarView) {

appendImage(calendarImage, toText: text)

}

func appendAvatar(ofUser user: User, toText text: NSMutableAttributedString) {

if let avatarImage = user.avatar {

appendImage(avatarImage, toText: text)

} else {

appendDefaultAvatar(ofUser: user, toText: text)

downloadAvatarImage(forResource: user.avatarResource)

}

func downloadAvatarImage(forResource resource: Resource?) {

if let resource = resource {

KingfisherManager.sharedManager.retrieveImageWithResource(resource,

optionsInfo: nil,

progressBlock: nil)

{ image, error, cacheType, imageURL in

if let _ = image {

dispatch_async(dispatch_get_main_queue()) {

NSNotificationCenter.defaultCenter().postNotificationName(TodoItemViewModel.viewModelViewUpdatedNotification, object: self.indexPath)

}

func appendDefaultAvatar(ofUser user: User, toText text: NSMutableAttributedString) {

if let defaultAvatar = user.defaultAvatar {

appendImage(defaultAvatar, toText: text)

}

func appendImage(image: UIImage, toText text: NSMutableAttributedString) {

text.appendAttributedString(TodoItemViewModel.spaceBetweenInlineImages)

let attachment = NSTextAttachment()

attachment.image = image

let yOffsetForImage = -7.0 as CGFloat

attachment.bounds = CGRectMake(0.0, yOffsetForImage, image.size.width, image.size.height)

let imageString = NSAttributedString(attachment: attachment)

text.appendAttributedString(imageString)

}

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.

Grouping

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:

private extension AppDelegate {
    
    func configureAppStyling() {
        styleNavigationBar()
        styleBarButtons()
    }
    
    func styleNavigationBar() {
        UINavigationBar.appearance().barTintColor = ColorPalette.ThemeColor
        UINavigationBar.appearance().tintColor = ColorPalette.TintColor
        
        UINavigationBar.appearance().titleTextAttributes = [
            NSFontAttributeName : SmoresFont.boldFontOfSize(19.0),
            NSForegroundColorAttributeName : UIColor.blackColor()
        ]
    }
    
    func styleBarButtons() {
        let barButtonTextAttributes = [
            NSFontAttributeName : SmoresFont.regularFontOfSize(17.0),
            NSForegroundColorAttributeName : ColorPalette.TintColor
        ]
        UIBarButtonItem.appearance().setTitleTextAttributes(barButtonTextAttributes, forState: .Normal)
    }
}

private extension AppDelegate {

func configureAppStyling() {

styleNavigationBar()

styleBarButtons()

}

func styleNavigationBar() {

UINavigationBar.appearance().barTintColor = ColorPalette.ThemeColor

UINavigationBar.appearance().tintColor = ColorPalette.TintColor

UINavigationBar.appearance().titleTextAttributes = [

NSFontAttributeName : SmoresFont.boldFontOfSize(19.0),

NSForegroundColorAttributeName : UIColor.blackColor()

]

}

func styleBarButtons() {

let barButtonTextAttributes = [

NSFontAttributeName : SmoresFont.regularFontOfSize(17.0),

NSForegroundColorAttributeName : ColorPalette.TintColor

]

UIBarButtonItem.appearance().setTitleTextAttributes(barButtonTextAttributes, forState: .Normal)

}

Or to group all notification logic together:

extension TodoListViewController {
    
    // called in init
    func addNotificationObservers() {
        NSNotificationCenter.defaultCenter().addObserver(self, selector: Selector("onViewModelUpdate:"), name: TodoItemViewModel.viewModelViewUpdatedNotification, object: nil)
        NSNotificationCenter.defaultCenter().addObserver(self, selector: Selector("onTodoItemUpdate:"), name: TodoItemDelegate.todoItemUpdatedNotification, object: nil)
    }
    
    func onViewModelUpdate(notification: NSNotification) {
        if let indexPath = notification.object as? NSIndexPath {
            tableView.reloadRowsAtIndexPaths([indexPath], withRowAnimation: .None)
        }
    }
    
    func onTodoItemUpdate(notification: NSNotification) {
        if let itemObject = notification.object as? ValueWrapper<TodoItem> {
            let updatedItem = itemObject.value
            let updatedTodoList = dataSource.listFromUpdatedItem(updatedItem)
            dataSource = TodoListDataSource(todoList: updatedTodoList)
        }
    }
}

extension TodoListViewController {

// called in init

func addNotificationObservers() {

NSNotificationCenter.defaultCenter().addObserver(self, selector: Selector("onViewModelUpdate:"), name: TodoItemViewModel.viewModelViewUpdatedNotification, object: nil)

NSNotificationCenter.defaultCenter().addObserver(self, selector: Selector("onTodoItemUpdate:"), name: TodoItemDelegate.todoItemUpdatedNotification, object: nil)

}

func onViewModelUpdate(notification: NSNotification) {

if let indexPath = notification.object as? NSIndexPath {

tableView.reloadRowsAtIndexPaths([indexPath], withRowAnimation: .None)

}

func onTodoItemUpdate(notification: NSNotification) {

if let itemObject = notification.object as? ValueWrapper<TodoItem> {

let updatedItem = itemObject.value

let updatedTodoList = dataSource.listFromUpdatedItem(updatedItem)

dataSource = TodoListDataSource(todoList: updatedTodoList)

}

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:

struct TodoItemViewModel {
    static let viewModelViewUpdatedNotification = "viewModelViewUpdatedNotification"
    
    let item: TodoItem
    let indexPath: NSIndexPath
    
    var delegate: ImageWithTextCellDelegate {
        return TodoItemDelegate(item: item)
    }
    
    var attributedText: NSAttributedString {
        return itemContent
    }
}

// ImageWithTextCellDataSource Protocol Conformance 
extension TodoItemViewModel: ImageWithTextCellDataSource {
    
    var imageName: String {
        return item.completed ? "checkboxChecked" : "checkbox"
    }
    
    var attributedText: NSAttributedString {
        return itemContent
    }
}

struct TodoItemViewModel {

static let viewModelViewUpdatedNotification = "viewModelViewUpdatedNotification"

let item: TodoItem

let indexPath: NSIndexPath

var delegate: ImageWithTextCellDelegate {

return TodoItemDelegate(item: item)

}

var attributedText: NSAttributedString {

return itemContent

}

// ImageWithTextCellDataSource Protocol Conformance

extension TodoItemViewModel: ImageWithTextCellDataSource {

var imageName: String {

return item.completed ? "checkboxChecked" : "checkbox"

}

var attributedText: NSAttributedString {

return itemContent

}

This also works great for separating out UITableViewDataSource vs UITableViewDelegate:

// MARK: Table View Data Source
extension TodoListViewController: UITableViewDataSource {
    
    func numberOfSectionsInTableView(tableView: UITableView) -> Int {
        return dataSource.sections.count
    }
    
    func tableView(tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
        return dataSource.numberOfItemsInSection(section)
    }
    
    func tableView(tableView: UITableView, cellForRowAtIndexPath indexPath: NSIndexPath) -> UITableViewCell {
        let cell = tableView.dequeueReusableCellWithIdentifier(String.fromClass(ImageWithTextTableViewCell), forIndexPath: indexPath) as! ImageWithTextTableViewCell
        let viewModel = dataSource.viewModelForCell(atIndexPath: indexPath)
        cell.configure(withDataSource: viewModel, delegate: viewModel.delegate)
        return cell
    }
}

// MARK: Table View Delegate
extension TodoListViewController: UITableViewDelegate {
    
    // MARK: Cell Selection
    func tableView(tableView: UITableView, didSelectRowAtIndexPath indexPath: NSIndexPath) {
        performSegueWithIdentifier(todoItemSegueIdentifier, sender: self)
    }
    
    // MARK: Section Header Configuration
    func tableView(tableView: UITableView, viewForHeaderInSection section: Int) -> UIView? {
        if dataSource.sections[section] == TodoListDataSource.Section.DoneItems {
            let view = UIView()
            view.backgroundColor = ColorPalette.SectionSeparatorColor
            return view
        }
        return nil
    }
    
    func tableView(tableView: UITableView, heightForHeaderInSection section: Int) -> CGFloat {
        if dataSource.sections[section] == TodoListDataSource.Section.DoneItems {
            return 1.0
        }
        
        return 0.0
    }
    
    // MARK: Deleting Action
    func tableView(tableView: UITableView, canEditRowAtIndexPath indexPath: NSIndexPath) -> Bool {
        return true
    }
    
    func tableView(tableView: UITableView, editActionsForRowAtIndexPath indexPath: NSIndexPath) -> [UITableViewRowAction]?  {

        let deleteAction = UITableViewRowAction(style: .Destructive, title: "Delete") { [weak self] action , indexPath in
            if let updatedTodoList = self?.dataSource.listFromDeletedIndexPath(indexPath) {
                self?.dataSource = TodoListDataSource(todoList: updatedTodoList)
            }
        }
        
        return [deleteAction]
    }
}

// MARK: Table View Data Source

extension TodoListViewController: UITableViewDataSource {

func numberOfSectionsInTableView(tableView: UITableView) -> Int {

return dataSource.sections.count

}

func tableView(tableView: UITableView, numberOfRowsInSection section: Int) -> Int {

return dataSource.numberOfItemsInSection(section)

}

func tableView(tableView: UITableView, cellForRowAtIndexPath indexPath: NSIndexPath) -> UITableViewCell {

let cell = tableView.dequeueReusableCellWithIdentifier(String.fromClass(ImageWithTextTableViewCell), forIndexPath: indexPath) as! ImageWithTextTableViewCell

let viewModel = dataSource.viewModelForCell(atIndexPath: indexPath)

cell.configure(withDataSource: viewModel, delegate: viewModel.delegate)

return cell

}

// MARK: Table View Delegate

extension TodoListViewController: UITableViewDelegate {

// MARK: Cell Selection

func tableView(tableView: UITableView, didSelectRowAtIndexPath indexPath: NSIndexPath) {

performSegueWithIdentifier(todoItemSegueIdentifier, sender: self)

}

// MARK: Section Header Configuration

func tableView(tableView: UITableView, viewForHeaderInSection section: Int) -> UIView? {

if dataSource.sections[section] == TodoListDataSource.Section.DoneItems {

let view = UIView()

view.backgroundColor = ColorPalette.SectionSeparatorColor

return view

}

return nil

}

func tableView(tableView: UITableView, heightForHeaderInSection section: Int) -> CGFloat {

if dataSource.sections[section] == TodoListDataSource.Section.DoneItems {

return 1.0

}

return 0.0

}

// MARK: Deleting Action

func tableView(tableView: UITableView, canEditRowAtIndexPath indexPath: NSIndexPath) -> Bool {

return true

}

func tableView(tableView: UITableView, editActionsForRowAtIndexPath indexPath: NSIndexPath) -> [UITableViewRowAction]? {

let deleteAction = UITableViewRowAction(style: .Destructive, title: "Delete") { [weak self] action , indexPath in

if let updatedTodoList = self?.dataSource.listFromDeletedIndexPath(indexPath) {

self?.dataSource = TodoListDataSource(todoList: updatedTodoList)

}

return [deleteAction]

}

Models

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.

struct User {
    let id: Int
    let name: String
    let avatarResource: Resource?
}

extension User {
    
    var avatar: UIImage? {
        if let resource = avatarResource {
            if let avatarImage = ImageCache.defaultCache.retrieveImageInDiskCacheForKey(resource.cacheKey) {
                let imageSize = CGSize(width: 27, height: 27)
                let resizedImage = Toucan(image: avatarImage).resize(imageSize, fitMode: Toucan.Resize.FitMode.Scale).image
                return Toucan.Mask.maskImageWithEllipse(resizedImage)
            }
        }
        return nil
    }
    
    var defaultAvatar: UIImage? {
        if let defaultImageView = DefaultImageView.viewFromNib() {
            defaultImageView.configure(withLetters: initials)
            if let defaultImage = UIImage.imageFromView(defaultImageView) {
                return Toucan.Mask.maskImageWithEllipse(defaultImage)
            }
        }
        
        return nil
    }
    
    var initials: String {
        var initials = ""
        
        let nameComponents = name.componentsSeparatedByCharactersInSet(.whitespaceAndNewlineCharacterSet())
        
        // Get first letter of the first word
        if let firstName = nameComponents.first, let firstCharacter = firstName.characters.first {
            initials.append(firstCharacter)
        }
        
        // Get first letter of the last word
        if nameComponents.count > 1 {
            if let lastName = nameComponents.last, let firstCharacter = lastName.characters.first {
                initials.append(firstCharacter)
            }
        }
        
        return initials
    }
}

struct User {

let id: Int

let name: String

let avatarResource: Resource?

}

extension User {

var avatar: UIImage? {

if let resource = avatarResource {

if let avatarImage = ImageCache.defaultCache.retrieveImageInDiskCacheForKey(resource.cacheKey) {

let imageSize = CGSize(width: 27, height: 27)

let resizedImage = Toucan(image: avatarImage).resize(imageSize, fitMode: Toucan.Resize.FitMode.Scale).image

return Toucan.Mask.maskImageWithEllipse(resizedImage)

}

return nil

}

var defaultAvatar: UIImage? {

if let defaultImageView = DefaultImageView.viewFromNib() {

defaultImageView.configure(withLetters: initials)

if let defaultImage = UIImage.imageFromView(defaultImageView) {

return Toucan.Mask.maskImageWithEllipse(defaultImage)

}

return nil

}

var initials: String {

var initials = ""

let nameComponents = name.componentsSeparatedByCharactersInSet(.whitespaceAndNewlineCharacterSet())

// Get first letter of the first word

if let firstName = nameComponents.first, let firstCharacter = firstName.characters.first {

initials.append(firstCharacter)

}

// Get first letter of the last word

if nameComponents.count > 1 {

if let lastName = nameComponents.last, let firstCharacter = lastName.characters.first {

initials.append(firstCharacter)

}

return initials

}

TL;DR

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.

stephencelis

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

This is from the first public stdlib file I could find: https://github.com/apple/swift/blob/master/stdlib/public/core/Algorithm.swift#L128-L140. The extensions are used purely for grouping. There are plenty more examples where extensions are used for protocol conformance (_e.g._ this set: https://github.com/apple/swift/blob/master/stdlib/public/core/Bool.swift#L30-L65).
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 🙂
https://tech.zalando.com/blog/speeding-up-xcode-builds/
- NatashaTheRobot
  
  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.
    http://www.slideshare.net/AvitoTech/objectivec-swift-avito
    slide number 10.
    So I think that this is still actual information.
    - NatashaTheRobot
      
      Thanks! Good to know. I still think readability trumps the compile time, but as the project gets bigger, it’s important to consider the tradeoffs!
    - Florian
      
      @natashatherobot:disqus The benchmark is based on this article (https://tech.zalando.com/blog/speeding-up-xcode-builds/), which uses this benchmark (https://github.com/diamondsky/swift-extensions-performance)
      
      I think the article and the benchmark are quite outdated, so probably Swift can do better now 😉
  - 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
- Kai Di Chen
  
  If you really wanted to override the methods from extensions at all, you might as well consider putting these methods back to the parent class.
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.
- NatashaTheRobot
  
  Yes! I recommend watching this: https://realm.io/news/andy-matuschak-controlling-complexity/
  - Vinicius Vendramini
    
    Great, thanks!
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. 🙂
Bruno Paulino

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.

Thanks
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?
Baljeet Singh

thanks for separating out UITableViewDataSource vs UITableViewDelegate……http://apptunix.com/ios-app-development/
ratna paul

Hey – I had a question about calling methods written in extension from the class instance methods. For example in the above the article we have created an extension for TodoListViewController and added a method – addNotificationObservers. However i believe this will be called either in viewDidLoad or viewWillAppear. Is it right to do so?
Scott Dickerson

This doesn’t seem to work for NSCoding protocol implementors, do you agree?
LegendLength

For separating private and public functions I would just put all the public stuff first in the class. No need to go looking for trouble by using extensions in a way that will trap other programmers.
Gutte

I totally agree and I love to work this way too