The Ultimate Battle — Struct vs Class Which one is best in Swift.

If you’ve ever danced with UIKit or AppKit (Apple’s OG user interface frameworks for iOS and macOS), you’ll know they’re all about the class act. 🕺💃 But SwiftUI? Nah, we like to strut our stuff with structs for our views! 😎 Why, you ask? Well, it’s not just because structs are the sprinters of the UI world. 🏃‍♂️💨 Let me sprinkle some fun facts your way.

First, let’s talk about performance — structs are like the Usain Bolt of UI components, fast and simple. 🏅💨 It’s not the whole shebang, but it’s like adding extra cheese on your pizza. 🍕 In the world of UIKit, every view is a class descended from UIView, carrying loads of baggage like a background color, constraints that dictate its moves, a layer for its artistic flair, and more. 🧳🎨 There’s a family reunion of properties and methods, and everyone’s invited.

Now, in SwiftUI, it’s all about those struct parties, where views are lightweight and carefree. 🎈🎉 Imagine having a struct holding just one integer — that’s the entire shebang! No hidden surprises from parent classes, grandparent classes, or great-grandparents. What you see is what you get! 🎁🙈

Thanks to our trusty iPhones, creating 1000 integers or even 100,000 is as quick as a magician’s disappearing act. 🧙‍♂️🐰 The same goes for SwiftUI views; they’re so snappy, you’ll forget there’s even a race. 🏁🚀

But hold your horses, speed isn’t the only superhero here. Structs also force us to be neat freaks with our state. 👮‍♂️ Classes can be a little messy, changing values left and right, leaving us in a tangled web — and how would SwiftUI ever keep up with that chaos?

By using immutable views, SwiftUI points us toward the zen of functional design. 🧘‍♀️ Our views become zen masters, serenely translating data into UI, instead of power-hungry overlords. 🙅‍♂️🤖

Look at the kinds of things that can be a view in SwiftUI — Color.red and LinearGradient. 🌈 They’re like simple, uncluttered souls who say, “Fill my space with red” and call it a day. 🎨☀️ On the other hand, UIView comes with a 200-page autobiography of properties and methods, inviting everyone to the party.

Trust me on this: Using a class for your view is like trying to breakdance on ice — it might look cool, but it won’t end well! 😂🕺 Stick with structs, and your code will be groovier than a disco night! 🕺🎉

Please follow Link to know more.

class EmployeeClass {
    var name: String
    var age: Int
    
    init(name: String, age: Int) {
        self.name = name
        self.age = age
    }
    
    func celebrateBirthday() {
        age += 1
    }
}

struct EmployeeStruct {
    var name: String
    var age: Int
    
    mutating func celebrateBirthday() {
        age += 1
    }
}

class Company {
    var employees: [EmployeeClass]
    
    init(employees: [EmployeeClass]) {
        self.employees = employees
    }
    
    func addEmployee(employee: EmployeeClass) {
        employees.append(employee)
    }
}

var companyClass = Company(employees: [])
for _ in 1...100000 {
    let employee = EmployeeClass(name: "John Doe", age: 30)
    companyClass.addEmployee(employee: employee)
}

var companyStruct = Company(employees: [])
for _ in 1...100000 {
    var employee = EmployeeStruct(name: "John Doe", age: 30)
    employee.celebrateBirthday()
    companyStruct.employees.append(employee)
}

In this example, we have two classes, EmployeeClass and Company, and a struct, EmployeeStruct. The EmployeeClass has properties for name and age, and a method to celebrate a birthday. The Company class manages an array of EmployeeClass instances.

On the other hand, EmployeeStruct is a struct with the same properties and a mutating method for celebrating a birthday.

We create two companies, one using EmployeeClass instances and the other using EmployeeStruct instances. We add 100,000 employees to both companies.

The performance concern here is that each time we update the age of an employee in the struct-based approach (using EmployeeStruct), we create a new instance of the struct, resulting in a lot of memory allocations and potential performance overhead. In contrast, with the class-based approach (using EmployeeClass), we directly modify the age property without creating new instances, which is more efficient.

This example showcases the importance of choosing the appropriate type (class or struct) based on the specific requirements and performance considerations of your application. In cases where you need mutability and minimal performance overhead, classes might be a better choice.

https://github.com/anandgupadhyay/Learning/blob/main/Learning/StructVsClass/StructVsClass.swift