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.