Zero configuration

The configurator in Clean Swift has two functions:

  1. Connect the VIP components using protocol conformance
  2. Set up the VIP cycle by connecting the output variables

Now that the protocols are no longer duplicated, the first function is not needed anymore. That leaves only the second.

It’s worthwhile to rethink if there’s a better way to set up the VIP cycle.

Among the feedback that I receive are:

  • Why does the configurator need to be a singleton? There is a newer, simpler way to make a singleton class.
  • Storyboards in Xcode have trouble recognizing the view controller subclass due to the protocol conformance specified by the extensions.
  • Some developers couldn’t use the templates out of the box because the configurator’s configure(viewController:) method is only invoked from UIViewController‘s awakeFromNib() method.

Keep reading to find out how each of these has been taken care of in the latest update.

The endless singleton debate

Singletons have a bad rep in the development world. Code smell. Bad design. Misuse. Overuse. Deservedly or not. You name it. That’s a topic for another day.

There are also the old Objective-C, and new Swift way of making a class singleton. Simpler syntax. Race condition. That’s out of scope here.

Also, the previous implementation actually didn’t prevent a developer from instantiating more than one instance of a singleton configurator. You just need to call the configurator’s default initializer instead of sharedInstance. Although you can safeguard against that by overriding the default initializer and making it private, so that it can’t be invoked. But there is no way to prevent a developer from adding another custom initializer to circumvent that.

Regardless of your opinion about singleton, a heated debate is sure to follow.

View controller class names aren’t recognized in storyboards

Whenever you create a UIViewController subclass, the first thing you do is to set the class name in the storyboard. One previous annoyance is that storyboards in Xcode cannot recognize the view controller class name due to its indexing order.

One way to get around that is to move the extensions out of the configurator and into the view controller. Now, Xcode can index properly, and storyboards can recognize your view controller classes.

But I don’t really like it. I think it’s bad to have to sacrifice readability for a tool’s shortcoming.

So I decided to wait, and hope Apple would fix it. But that hasn’t happened for two years. So I’m taking matters into my own hands this time.

Support for building UI in code

Most iOS developers use storyboards to build their UI. It’s super slick and easy. Apple has also been investing heavily in storyboards. Every WWDC, we see improvements to auto layout, size classes, view debugging, and much more in terms of Xcode support.

But you can’t argue there are some situations where building the UI in code makes more sense. Especially in some self-contained UIView subclasses or frameworks.

So, I really want to make Clean Swift work for those who build the UI in code instead of storyboard. For whatever reasons.

Less is more – Yay!

In the latest update of the Clean Swift Xcode templates, the configurator is gone. It’s removed in favor of just one setup() method in the view controller.

First, you won’t have to worry about singleton anymore.

Second, because there is no more duplicate protocol, your beautifully named UIViewController subclasses can now be recognized in the storyboards for your autocompletion pleasure.

Third, by hooking into UIViewController’s initializers – init(nibNameOrNil:nibBundleOrNil:) and init?(aDecoder:), Clean Swift now works for those who prefer to build their UIs in code.

Lastly, there is one fewer class and file. It should speed up Xcode’s indexing and build time.

Get the Clean Swift Xcode Templates

Subscribe below to get my Xcode templates and learn how to apply the VIP cycle to your projects, extract business and presentation logic into interactor and presenter, navigate to different scenes using multiple storyboards, and write fast, maintainable tests with confidence to make changes.

I promise I'll never send you spam. You can unsubscribe at any time.

Raymond

I’ve been developing in iOS since the iPhone debuted, jumped on Swift when it was announced. Writing well-tested apps with a clean architecture has been my goal.

4 Comments

  1. Hey Raymond,

    Thanks for the amazing templates! It’s really good. However I was using version 2.x, I’m half way through my project. What’s the best route to update to the new version?

    1. Hi Fred,

      I suggest creating new scenes with the latest template version to get familiar with the changes first. Then, you can decide if it’s worthwhile to update your existing scenes to the latest templates. You don’t have to because they still work. Each scene is on its own.

  2. Hey Raymond,
    I have a question regarding an edge case: would it be possible to reuse the VC in two different scenes? Given the fact that the ViewController is setting up the interactor, what would be the best way to have two scenes with different business logic, thus different interactor that could reuse the same ViewController?

    Thanks for your thoughts!

    1. Hi Mihai,

      In practice, it’s very rare that you want to reuse a view controller. But if you do, you can always pull out the setup() method out of the view controller and into a configurator for your scene. Alternatively, you can look into promoting the view controller to a superclass, and then you can create two subclasses from it, one for each scene. You can simply override the setup() method to hook up different components.

Leave a Comment

Your email address will not be published. Required fields are marked *