Applying SOLID Principles in iOS Development with SwiftUI

 

The SOLID principles are a set of design guidelines that help developers create maintainable, scalable, and robust software. These principles are especially important in iOS development, where apps often grow in complexity over time. In this blog, we’ll explore how to apply SOLID principles in a SwiftUI-based iOS app, complete with code examples.

What are SOLID Principles?

SOLID is an acronym for five design principles:

1. Single Responsibility Principle (SRP)
2. Open/Closed Principle (OCP)
3. Liskov Substitution Principle (LSP)
4. Interface Segregation Principle (ISP)
5. Dependency Inversion Principle (DIP)

Let’s dive into each principle and see how it applies to SwiftUI.

1. Single Responsibility Principle (SRP)

Definition: A class or module should have only one reason to change, meaning it should have only one responsibility.

Example in SwiftUI

Suppose you’re building a UserProfileView that displays user information and handles user interactions. Instead of putting all the logic in the view, we can separate concerns.

Before (Violating SRP):

struct UserProfileView: View {
    @State private var user: User
    @State private var isLoading = false

var body: some View {
        VStack {
            if isLoading {
                ProgressView()
            } else {
                Text(user.name)
                Text(user.email)
                Button("Refresh") {
                    isLoading = true
                    fetchUserData()
                }
            }
        }
    }
    private func fetchUserData() {
        // Network request logic here
    }
}

After (Following SRP):

// Separate network logic into a service
class UserService {
    func fetchUser() async -> User {
        // Simulate network request
        try? await Task.sleep(nanoseconds: 1_000_000_000)
        return User(name: "John Doe", email: "john@example.com")
    }
}

// View only handles UI
struct UserProfileView: View {
    @State private var user: User?
    @State private var isLoading = false
    private let userService = UserService()
    var body: some View {
        VStack {
            if isLoading {
                ProgressView()
            } else if let user = user {
                Text(user.name)
                Text(user.email)
                Button("Refresh") {
                    Task {
                        await refreshUser()
                    }
                }
            }
        }
    }
    private func refreshUser() async {
        isLoading = true
        user = await userService.fetchUser()
        isLoading = false
    }
}

Key Takeaway: The UserProfileView now only handles UI rendering, while the UserService handles data fetching. This separation makes the code easier to maintain and test.

2. Open/Closed Principle (OCP)

Definition: Software entities (classes, modules, functions) should be open for extension but closed for modification.

Example in SwiftUI

Suppose you have a PaymentProcessor that processes payments. Instead of modifying the existing class to add new payment methods, you can extend it using protocols.

Before (Violating OCP):

class PaymentProcessor {
    func processPayment(type: String) {
        if type == "CreditCard" {
            print("Processing credit card payment")
        } else if type == "PayPal" {
            print("Processing PayPal payment")
        }
    }
}

After (Following OCP):

protocol PaymentMethod {
    func process()
}

class CreditCardPayment: PaymentMethod {
    func process() {
        print("Processing credit card payment")
    }
}
class PayPalPayment: PaymentMethod {
    func process() {
        print("Processing PayPal payment")
    }
}
class PaymentProcessor {
    func processPayment(method: PaymentMethod) {
        method.process()
    }
}

Key Takeaway: You can now add new payment methods without modifying the PaymentProcessorclass.

3. Liskov Substitution Principle (LSP)

Definition: Subtypes must be substitutable for their base types without altering the correctness of the program.

Example in SwiftUI

If you have a base class Shape and subclasses like Circle and Square, they should behave consistently.

protocol Shape {
    func area() -> Double
}

struct Circle: Shape {
    let radius: Double
    func area() -> Double {
        return .pi * radius * radius
    }
}
struct Square: Shape {
    let side: Double
    func area() -> Double {
        return side * side
    }
}

Key Takeaway: Both Circle and Square can be used interchangeably wherever a Shape is expected.

4. Interface Segregation Principle (ISP)

Definition: Clients should not be forced to depend on interfaces they do not use.

Example in SwiftUI

Instead of having a single large protocol, break it into smaller, more specific protocols.

Before (Violating ISP):

protocol Worker {
    func work()
    func eat()
}

class Human: Worker {
    func work() { print("Working") }
    func eat() { print("Eating") }
}
class Robot: Worker {
    func work() { print("Working") }
    func eat() { /* Robots don't eat! */ }
}

After (Following ISP):

protocol Workable {
    func work()
}

protocol Eatable {
    func eat()
}
class Human: Workable, Eatable {
    func work() { print("Working") }
    func eat() { print("Eating") }
}
class Robot: Workable {
    func work() { print("Working") }
}

Key Takeaway: Robot no longer needs to implement unnecessary methods.

5. Dependency Inversion Principle (DIP)

Definition: High-level modules should not depend on low-level modules. Both should depend on abstractions.

Example in SwiftUI

Instead of directly instantiating dependencies, inject them.

Before (Violating DIP):

class UserManager {
    private let storage = FileStorage()

func saveUser(_ user: User) {
        storage.save(user)
    }
}

After (Following DIP):

protocol Storage {
    func save(_ user: User)
}

class FileStorage: Storage {
    func save(_ user: User) {
        // Save to file
    }
}
class UserManager {
    private let storage: Storage
    init(storage: Storage) {
        self.storage = storage
    }
    func saveUser(_ user: User) {
        storage.save(user)
    }
}

Key Takeaway: UserManager now depends on the Storage protocol, making it more flexible and testable.

Conclusion

By applying SOLID principles in your SwiftUI projects, you can create apps that are easier to maintain, extend, and test. Here’s a quick recap:

1. SRP: Keep components focused on a single responsibility.
2. OCP: Design systems that are open for extension but closed for modification.
3. LSP: Ensure subtypes can replace their base types without issues.
4. ISP: Break down large interfaces into smaller, specific ones.
5. DIP: Depend on abstractions, not concrete implementations.

By following these principles, you’ll write cleaner, more modular, and scalable SwiftUI code. Happy coding! 🚀