TLDR:
Classes:
- Are referenced
- Can inherit from other classes.
- Have a de-initializer
- Have an identity (‘===’).
- Allocated on the heap – reference maintained on the stack.
Structs:
- Are copied, not referenced.
- Can implement protocols
- Allocated on the stack
Why this question?
This question gets asked a lot in interviews. In fact, I don’t even remember an interview in which this discussion was not bought up in some form.
More than likely, though, this gets asked of you in a telephone interview – I think I should write about the different types of iOS interviews out there – but that is for another post.
Going back to the telephonic interview – the hiring team quickly wants to figure out if you are worth talking to – they want to know if you know the basics and if you would be able to meet the hiring bar if invited for an on-site interview.
And this question is perfect for that.
If you can’t explain the difference between a Struct and Class in a couple of sentences – you have never worked with Swift or you aren’t paying attention to details – in both cases, the company would likely not want to hire you. (sorry, but true).
Basics
First off, Structs are value types, whereas Classes are reference types. That means a new copy of data is created every time you pass a Struct around. Whereas for classes, new references keep pointing to the same location in memory when accessing data.
This makes Structs inherently safer than Classes – with a Struct, another thread will never be able to modify a value you are holding on to. Instead, the thread will get a new copy of the data and can only modify its local copy.
With Classes, on the other hand, you have to be cautious when working with multiple threads – since a different part of code could be pointing to the reference you are holding on to – issues such as data corruption or unintended side effects are more likely.
In a telephonic screen – the interviewer might just stop you at this point and move on to the next question since it is clear you understand the most fundamental difference between a Struct and Class.
Other differences
Classes support inheritance which Structs do not. (Inheritance mostly causes more issues than it resolves, but that’s for another blog post, I guess). But if your specific use case is a good fit for inheritance, you have to choose Classes over Structs for data modeling.
Classes also have a ‘denit’ method which gets called just before the object is released from memory – this could be useful to clean up any resources you might be holding on to in the Class. With Structs, since they are allocated on the stack (and are treated as values), there is no equivalent method.
Immutability difference
A Struct created with a let keyboard is immutable – both the reference and the values inside. That means the reference cannot point to another Struct, and the values cannot be modified in the future.
However, a Class reference created with a let keyboard allows values inside to change, but the reference is immutable.
Which one to use?
Structs should normally be your default choice when modeling state in your app because of the thread safety associated with value types – using Structs also makes your code much easier to reason about since you need to only focus on a method/block of code without worrying about another part of the app modifying state.
However, you would be better off starting with a Class in the following scenarios:
- You need interoperability with Objective C.
- Reference-based modeling makes sense for your use – i.e., you want to share state between your apps threads and use the side effects to propagate state changes.
- You want to use Identity checks (‘===‘) for equality.
Indrajit Shanbhag 