As developers, we’re in a unique position where we can create our own tools. If nothing fits our needs, we can make our own! Isn’t that an empowering feeling? Today, I want to share with you a simple
UIViewController base class that I built as tool for myself.
I affectionately call it the
UIStackView, inside a
UIScrollView, inside a view controller. As simple as that.
In this article, you’ll learn:
- When you should create your own UIViewController base class.
- When to subclass a UIViewController and when to use composition.
- The three rules I follow to create your own robust base controllers that won’t be a pain to maintain.
Let’s look at how we can make it work.
Why do this?
Building a base view controller is an important philosophical decision. Whenever you add an extra layer to your inheritance chain, there needs to be a darn good reason for it.
Long inheritance chains are maintenance nightmares. Have you ever worked on an app with some sort of class called
MyAppBaseViewController? You change something inside and suddenly new bugs are popping up everywhere?
Yeah. It’s an awful feeling.
More often than not, we can use composition instead of subclassing to get the results we want. This should be your first reflex: break things down into manageable parts and then mediate between them. It helps prevent Massive View Controllers and it’ll make your codebase far more enjoyable to work in.
However, sometimes what we really need is a base class. We want to change the very underlying thing we’re working with. I often find myself doing this for controllers when I need generic, custom UI. However, in order to maintain a healthy project, I have a few guidelines that I follow to make sure my foundations don’t give out from under me.
The 3 rules for great UIViewController subclasses
In order to create a great base view controller, these are the three rules that I follow:
- No business logic
- Support the rest of the public API
- No external dependencies
Let’s take a quick look at all of these in turn.
No business logic
The first and most important guideline is simple: no business logic in your view controller. The reasons are numerous: we want this class to be reusable no matter where we are in our app. We want it to be focused and have clear responsibilities.
But don’t get me wrong, I understand the temptation! Adding business logic to a base view controller makes things easy. Everything you need is right there! But seriously, can you imagine if
UITableViewController had a
Yeah, makes no sense 🤓
Support the rest of the public API
The second guideline is to properly support the rest of the API. This is especially important if you plan on reusing this in the future. Six months from now, you’re not going to remember that
addSubview: causes a crash if Jupiter isn’t aligned with Saturn 🌝
This also benefits the rest of your team. They’re going to be using your class as well, and it should behave like a normal view controller as much as possible.
It’s important to point out that some of the legacy UIKit APIs don’t follow this guideline. Take
UITableViewController, for example. Have you ever tried using
addSubview: to add some floating UI on top of it? And then you headed straight to StackOverflow, right?
Well that’s exactly what I mean. Support the underlying API.
UICollectionViewController’s more modern API properly supports this. Thanks, UIKit team!)
No other dependencies
Finally, it’s important for me that my base view controller be portable from project to project. That means absolutely no outside dependencies.
Yeah, using SnapKit would be easier than creating Autolayout constraints manually, but my next project may not use SnapKit. Maybe it’ll use Anchorage or Cartographer. I wouldn’t want to introduce a new dependency just so I can use my controller.
Actually building the thing
Alright, enough talk, let’s build this thing!
StackViews and ScrollViews
Our class starts off simple enough: a view controller subclass with a scroll view and a stack view. Note that this class is
open since we want to be able to subclass it if needed, even outside of its own module.
Next, we override the
loadView method. This is where we’ll set up our views and constraints. Lucky for us, UIStackView and UIScrollView play well together if their constraints are set up correctly 😇
Finally, we create our public API. I wanted to add convenience methods to add and remove the views that I’m stacking, so that’s below.
This would also be an excellent place to add methods for spacer views, separators, and other convenience methods if you’re into that stuff :)
And there you go! Your very own
StackViewController is ready to go!
I find this controller particularly useful when building forms or any UI that will need to scroll when the keyboard is present.
Finally, I have one last tip for building this type of “library” code:
Give it its own Xcode project and add it to your main project’s workspace. As such, it’ll be defined in a separate module you’ll able to better assess what should be public and private through actual usage.
It’ll also be easier to version, and keep track of changes.
I hope you enjoyed this short philosophical dive into base view controllers! The key takeaway here is avoid them if you can.
But if you can’t, now you can build base VCs that won’t break every other commit!
Happy coding! ✌️