Swift Classes – You Don’t Really Need To Understand Them.

Of course, that’s not actually true. If you want to become an expert Swift programmer, you absolutely need to understand classes. However, I believe you don’t really need to know that much about classes to get going with them. In fact, the first time you use them you probably won’t even really be aware of it other than there’s a “class” keyword in your code at the top.

Tutorials might have confused you.

At least, I was confused. Most of the explanations I read/watched about classes went something like this:

“A class lets you create a custom object. For example, say you wanted to create an Animal class, you’d do it like this:”

class Animal {
 let greeting = "I am an animal"

“Now you can create multiple Animal instances from the original design you created in Animal, like this:”

let animal1 = Animal()
let animal2 = Animal()
let animal3 = Animal()

“Now create a subclass, that lets you use all of the stuff Animal had, and customize further for this subclass. Our subclass will be Dog:”

class Dog: Animal {
 let species = "I am specifically a dog"

“And now you can create as many Dogs as you want, an army of them in fact, all with the powers of both Animal and Dog:”

let myDog1 = Dog()
let myDog2 = Dog()
let myDog3 = Dog()

print("\(myDog1.greeting). \(myDog1.species)")
print("\(myDog2.greeting). \(myDog2.species)")
print("\(myDog3.greeting). \(myDog3.species)")

And the tutorial would go on to explain properties, methods, etc. That’s super cool, and those are indeed the magical powers of classes and object oriented programming. When I first saw this kind of explanation, the concept totally made sense in my head. I was totally on board with the logic.

But how to use them?

But then I went to try and write an app of my own, and found I had no idea why anyone would ever use classes in actual code. Sure it’s all fun with animals, dogs and cats, but I was way more concerned about how I would get my app to show an image or a button, for starters. That’s the level I was at. But there was the class keyword staring at me when I created a new project in Xcode, without ever writing a single line of code on my own. It appears in the freebie stuff Xcode gives you when you create a fresh storyboard-based project:

class ViewController: UIViewController {

    override func viewDidLoad() {
        // Do any additional setup after loading the view.

Why is class there? And it’s not just a class, it’s a subclass. To be honest, understanding why isn’t really necessary to get your app to fire up for the first time, or to get an image on the screen, or put some basic logic behind a button.

I’ve realized that to create a basic app, you don’t need to worry about creating classes from scratch, or much less create subclasses of your custom classes to use abstract object oriented constructs such as polymorphism or multiple inheritance. The most immediately applicable use of a class is right there in that first bit of code that Xcode populates for you.

There’s a swift class right front of you

If you think about what the Apple developers might have been thinking when they were cooking up Xcode, they can’t possibly know what your app is going to do. At some point, they have to hand some control of the screen to your app. The way they accomplished this was to create UIViewController, which does a bunch of stuff you can’t see to create a blank screen on the phone, ready to be customized for some interesting and unique things your app will do. If you don’t customize UIViewController, all your app will ever be is a blank screen. By creating a subclass of UIViewController (Apple assumes you want to call this ViewController), you can now write your own custom stuff to show beautiful things on the screen. You don’t really realize it, but you’re using inheritance.

The subclassing in this line lets you customize the view:

class ViewController: UIViewController

But where does the handoff take place? When does Apple hand off the view to your app? As it turns out, viewDidLoad() is a function that Apple already wrote. Like the name suggests, it loads up the view. But if you don’t customize it, it’ll just be a blank view of nothing. That’s why you need to “override” viewDidLoad to customize it, so you can start running your own code. That’s what’s happening here:

override func viewDidLoad()

But there’s one last thing to do in your now-overridden viewDidLoad function. Since you overrode it, the original Apple code to load up the blank view won’t run. So you have to run it with:


At this point, you’re finally ready to write your own custom code for your app.

As you keep coding, you’ll realize that subclassing Apple-created classes like this is really helpful when you want to do all sorts of things, and the inheritance concept will make a very real-world kind of sense.

I really think that’s a more realistic approach than an Animal/Dog/Cat example of classes, which makes sense after you’ve had a lot of experience.

I hope that helps! Happy coding!

Leave a Reply

Your email address will not be published.