When developing with Swift, you eventually encounter a moment that makes you pause.
“Should I make this a class or a struct?”
When I first learned Swift, I chose between them based on intuition. After running into strange bugs, I finally studied the difference properly.
Let me give you the conclusion first.
Unless you have a specific reason, choose a struct first.
Use a class only when you genuinely need “one shared state.”
Apple’s official guidelines take the same position. Today, I’ll explain why step by step.
Key Takeaways (3 Points)
Here’s a quick summary for busy readers.
- A struct is a value type. Copying it creates a completely separate value.
- A class is a reference type. Copies still point to the same instance.
- If you’re unsure, start with a struct; use a class only when you need inheritance or shared state.
Remember these three lines and you’re halfway there.
What’s the Difference Between Value Types and Reference Types?
It sounds confusing when explained only in words. Looking at code is the fastest way.
First, structs. The moment you copy one, the two values become completely independent.
struct Point { var x = 0 }
var a = Point()
var b = a // Value copied
b.x = 10
print(a.x, b.x)
// Output: 0 10Even if you change b, a stays the same because each has its own value.
Now, classes. The code looks similar, but the result is different.
class Box { var x = 0 }
let a = Box()
let b = a // Reference copied (same object)
b.x = 10
print(a.x, b.x)
// Output: 10 10We changed only b, but a became 10 too.
That’s because both point to the same instance. This was exactly the bug that gave me trouble.
So Which One Should You Use, and When? (Selection Criteria)
When making this decision in production, I keep this table in mind.
| Situation | Choice |
|---|---|
| A model that simply stores data | Struct |
| Values should remain independent after copying | Struct |
| Inheritance is required | Class |
| The same instance is shared across multiple places | Class |
| Interoperability with Objective-C is required | Class |
Here’s the same idea in a little more detail.
- For values themselves, such as coordinates, colors, and sizes, a struct is the natural choice.
- When multiple parts of the app need to observe one shared state, such as a view controller or network manager, use a class.
- Apple’s SwiftUI also makes View a struct for the same reason: it’s lightweight and predictable.
For reference, Array, String, and Dictionary in the Swift standard library are all structs. That shows how fundamental value types are.
Why Recommend Structs First?
Value types are predictable.
You don’t have to worry about a value you passed being changed behind your back elsewhere. Even when passed to a function, the original remains safe.
They’re also reassuring in multithreaded environments. Without shared state, data races are less likely.
Classes are powerful but require care. When the same instance is held in many places, it becomes difficult to track where its value changes.
That’s why the habit of “struct by default, class only when needed” can greatly reduce bugs.
When to Use Them—and When to Avoid Them
Here are the decision criteria in a compact form.
- Use a struct: data-centric models, when independent copies are needed, and when thread safety matters
- Use a class: when inheritance is needed, when one instance must be shared, or when identity matters
- Avoid: habitually using a class for a simple model, or forcing a struct workaround when sharing is required
How This Comes Up in Interviews
Q. What is the biggest difference between structs and classes?
Structs are value types, while classes are reference types. Copying a struct creates a completely independent value, whereas copying a class still points to the same instance. Only classes support inheritance and deinit.
Q. Why does Swift recommend using structs?
Value types have no shared state, so they cause fewer side effects and are more predictable. The original cannot be changed unintentionally, and their safety in multithreaded environments helps reduce bugs.
At first, I thought these were merely syntax differences, but the deeper I looked, the more I realized they were design choices.
Get these criteria under your fingers today and you’ll hesitate less in your next project. Start by asking: value or shared state?