Swift 3.0 Refactoring Cues

I’ve been upgrading the try! Swift app to Swift 3.0 for what feels like 3 days now (I’ve had to take a lot of breaks to be in the right patient mindset, especially with not knowing how many more errors will come up after the immediate ones were fixed).

But anyway, this morning my BUILD SUCCEEDED!! I fixed the final warnings (almost) and tried out the app to see that it works generally. I still have time to fix any bugs in the future before the next version goes in production.

And although the process was definitely frustrating, a lot of the things that needed fixing were very repetitive. For example, the String API has added a new (and very ugly IMHO) describing parameter:

Well, I have A LOT of TableViewCell’s in my app, and when combined with registering Nibs or Dequeuing Cells, it was just an ugly train wreck:

I had to fix these with the describing and .self over and over again during my Swift 3.0 upgrading process. As soon as I finished the upgrade, I knew I had to fix this issue. After all, hopefully the String API will be fixed back to having no describing parameter in Swift 4 – I want to refactor this repetitive change in only one place in the future!

The Refactor

Luckily, in this case, I knew just the solution! In fact, I talked about this solution in my POP talk… I should definitely have implemented this earlier, but when I first started making the app, I didn’t know about it, and it hasn’t been a big enough issue to actually do the refactor until this painful Swift 3.0 upgrade 😬

All it took was a few minutes and a few protocols! A timely reminder of how awesome Swift actually is! For a more detailed explanation, make sure to watch my talk or read about it from the source here. Otherwise, here is the quick version:

First, create a Protocol with a default variable for generating the nib name string from the class name:

Next, do the same thing to generate the reuse identifier string from the cell class:

Now the good stuff! You can take advantage of the above protocols to simplify the nib registration and cell dequeuing:

Now time to refactor!

Here is my full commit. I was very happy with this result and look forward to less repetition when upgrading to Swift 4.0 in the future!

So although the Swift 3.0 upgrade is very painful, it is also a good time to notice all those repetitive things in your code and refactor.

Happy upgrading and remember to Breathe!

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

  • Mike

    Hi) I think you will can add this line somewhere in your uiview extension

    extension UIView: Reusable View { }

    and after this all your views will have identifiers )

    • It’s there! Just hard to see at the bottom of the protocol: extension UITableViewCell: ReusableView { }

  • Михайло Вишневський

    And you can create same protocol for view controller

    import UIKit

    protocol ReusableViewControllerProtocol: class { }

    extension ReusableViewControllerProtocol where Self: UIViewConroller {
    static var storyboardId: String {

    return String(self)

  • Mariusz Lisiecki

    Actually there is a very nice github project for this (however, with swift 3 branch not yet merged):

  • Frederik Winkelsdorf

    Note to myself: You know you are getting better, if the approach Natasha took now is the same you’d chosen 8 months ago ^^ See this Gist and my comment: https://gist.github.com/IanKeen/4ecbffea1e9d0c1bf1d6. Good to have this way of thinking in common 🙂

  • Interesting implementation. I have not yet fixed many upgrade issues since I started working on a new app altogether. But I will have to do these things sooner or later. Bookmarking this article for future reference. Thanks.