In Swift, both structs and classes are used to define custom data types, but there are some key differences between them. Here are the main distinctions:

1. Value vs. Reference Types:
Struct: Structs are value types. When you create an instance of a struct and assign it to a new variable or pass it to a function, a copy of the instance is created. Each copy is independent, and modifications to one instance do not affect the others.
Class: Classes are reference types. When you create an instance of a class and assign it to a new variable or pass it to a function, both variables point to the same instance in memory. Modifications made to one reference affect all other references to the same instance.

2. Mutability:
Struct: By default, all properties of a struct are immutable (constant) unless you explicitly mark the instance as `var` (mutable).
Class: Properties of a class can be changed regardless of whether the class instance is declared as `let` or `var`.

3. Inheritance:
Struct:  Cannot inherit from other types and cannot be subclassed.
 Class:  Supports inheritance, and you can create subclasses to inherit properties and behavior from a base class.

4. Initialization:
Struct:  Automatically generates a memberwise initializer by default. You can also create your custom initializers.
Class:  Does not automatically generate a memberwise initializer. You need to provide your initializers.

5. Deinitialization:
Struct:  Does not support deinitializers.
Class:  Supports deinitializers, which are called when an instance of the class is deallocated.

6. Usage Recommendation:
Struct: Use when the data is relatively small and is expected to be copied frequently (e.g., geometric shapes, points, colors).
Class: Use when you need reference semantics, inheritance, or when dealing with larger and more complex data structures.

Here's a simple example illustrating the difference:

```swift
struct Point {
    var x: Double
    var y: Double
}

class PointClass {
    var x: Double
    var y: Double
    
    init(x: Double, y: Double) {
        self.x = x
        self.y = y
    }
}

var point1 = Point(x: 1.0, y: 2.0)
var point2 = point1
point2.x = 3.0

var pointClass1 = PointClass(x: 1.0, y: 2.0)
var pointClass2 = pointClass1
pointClass2.x = 3.0

print(point1.x)        // 1.0
print(point2.x)        // 3.0 (independent copy)
print(pointClass1.x)    // 3.0 (both references point to the same instance)
print(pointClass2.x)    // 3.0 (both references point to the same instance)
```

Create a memory leak with Class
In Swift, the issue of reference cycles leading to memory leaks is typically addressed using weak references. If you have a class with a method that could potentially create a reference cycle, using `weak` or `unowned` references is a common approach.

Here's a basic example in Swift:

```swift
class MyClass {
    var otherInstance: MyClass?

    func setReference(otherInstance: MyClass) {
        self.otherInstance = otherInstance
    }
}

// Creating instances
var obj1: MyClass? = MyClass()
var obj2: MyClass? = MyClass()

// Creating a reference cycle
obj1?.setReference(otherInstance: obj2!)
obj2?.setReference(otherInstance: obj1!)

// Breaking the reference cycle using weak references
weak var weakObj1 = obj1
weak var weakObj2 = obj2

// Setting references to nil
obj1 = nil
obj2 = nil

// At this point, the reference cycle is broken, and both objects can be deallocated
print(weakObj1) // nil
print(weakObj2) // nil
```

In this Swift example, `weak` is used to create a weak reference. The weak references won't keep the objects alive, and when you set `obj1` and `obj2` to `nil`, the reference cycle is broken, allowing the objects to be deallocated.

It's important to choose between `weak` and `unowned` based on your specific use case. `weak` references can become `nil` when the object they reference is deallocated, while `unowned` references assume that the object being referred to is always alive and will crash if accessed after it's deallocated. The choice between them depends on whether the reference is expected to be optional or not.
Back to Top