Swift Classes vs. Structs – Why You Shouldn’t Care About The Difference

Like all iOS developers at some point early in their app-building journey, you may be wondering what the difference is, when to use one over the other, and why you should care. If you’re at this point, especially if you’re new to programming, I’d highly recommend not caring. That view might make the Internet mad, but after learning the major differences and reading the Apple documentation, I would still make that recommendation. If you’re an experienced developer, you’ve already made your decision and not only done the research, you understood what you were reading. But for the rest of us non-super geniuses, classes and structs can be a pretty abstract concept that’s hard to wrap your head around. In the end, I think you can build a basic app using either one, and until your app’s performance is hindered by the improper use of one or the other, why not just focus on more pressing matters?

They both do the same thing

This isn’t entirely true, and under the hood they’re fundamentally different, but if you’re at a point where you need to create a custom object – just pick one and move on. The first time I found I was really forced to create my own object was when I needed to read and write JSON. The hippest coolest way to deal with JSON these days in Swift is to use the Codable protocol. The only issue is both structs and classes can do the codable thing:

struct JamesStruct: Codable {
    var key:String = "value"

class JamesClass: Codable {
    var key:String = "value"

So which one to use, then? The StackOverflow example I found somewhere and mercilessly copy/pasted used a struct, so I just went with that without really understanding why. Is that so wrong? I mean come on, we’ve all done it. Even the most advanced, highly-paid, successful and super genius developers out there have quickly scraped StackOverflow because they were on a deadline. Anyone who says otherwise is likely selling something.

You need context to really understand the difference

I always need some sort of context to really understand how something works. Sure I could conjure up some pie-in-the sky example for you to illustrate the differences between these two, but there’s a zillion blogs out there already that have done that for you. Not to mention if you’re looking for pie in the proverbial sky, the official Apple guidance on the topic is here:


I could say that classes are a reference type and structs are a value type, that structs are “lightweight” and classes are “heavier”, or that only classes can inherit. But it probably doesn’t mean much to you unless it specifically affects YOUR app and YOUR use case somehow.

If you’re debating which one to use in your app, or wondering if you used them correctly, why not just play around a bit? See what happens when you substitute one for the other. That’s where you’ll really learn.

If you need a hard recommendation, Apple says default to structs

If you checked out the official Apple guidance, you might have noticed they said to use structs (as of this writing, end of 2021) unless you have a specific reason to use classes. Which brings me to the image at the start of my post – I was surprised to learn that many of the basic data types in Swift like Strings and Int’s are, in fact, structs. If Apple is using them in that capacity I think it’s safe to say your custom object is mostly likely a good candidate for a struct.

Happy coding!

Leave a Reply

Your email address will not be published.