Keep Spaghetti in the Kitchen, Not in Your Swift Code: Mastering SOLID 🍝

alphonse — Wed, 03 Jun 2026 08:31:23 +0000

Hey iOS Devs! 👋

Don't get me wrong, I love a good plate of Spaghetti Carbonara. But when it comes to iOS development, spaghetti belongs in the kitchen, not in our codebases. 🍝

You open a project, and boom a 2,000-line ViewController staring right at your soul. It handles networking, parses JSON, updates the UI, and formats dates all at the same time. Welcome to the infamous Massive View Controller.

If you want to escape this spaghetti code nightmare and build iOS apps that are scalable, maintainable, and 100% testable, you need to master SOLID Principles.

Before we dive into the 5 golden rules, we have to pay our respects to the master chefs who saved us from starvation (read: bad code).

Huge appreciation goes to Robert C. Martin (affectionately known as "Uncle Bob"), who introduced these principles back in the early 2000s, and Michael Feathers, who later cleverly rearranged them into the catchy S.O.L.I.D acronym we know today.

Without their recipe for clean architecture, we’d all still be drowning in a never-ending bowl of code-spaghetti. 🫡

So, let's look into the kitchen cabinet and break down these 5 ingredients one by one.

1. Single Responsibility Principle (SRP)

"A class should have one, and only one, reason to change."

In short: One class = One job.

❌ Don't Do this (The "Do-It-All" Class)

class ProductViewController: UIViewController {
    func fetchProducts() {
        let url = URL(string: "[https://api.example.com/products](https://api.example.com/products)")!
        URLSession.shared.dataTask(with: url) { data, _, _ in
            let products = data.flatMap { try? JSONDecoder().decode([Product].self, from: $0) }
            DispatchQueue.main.async { self.tableView.reloadData() }
        }.resume()
    }
}

✅ Do this

Separate the networking logic from the UI. Let a dedicated service handle data fetching.

class NetworkManager {
    func fetchProducts(completion: @escaping ([Product]?) -> Void) {
        let url = URL(string: "[https://api.example.com/products](https://api.example.com/products)")!
        URLSession.shared.dataTask(with: url) { data, _, _ in
            let products = data.flatMap { try? JSONDecoder().decode([Product].self, from: $0) }
            completion(products)
        }.resume()
    }
}

class ProductViewController: UIViewController {
    let networkManager = NetworkManager()
    // Now this class only cares about the UI!
}

2. Open/Closed Principle

"Software entities should be open for extension, but closed for modification"

You should be able to add new features without breaking or modifying your existing, battle-tested code. In Swift, Protocols are your superpower for OCP.

❌ Don't Do this

Every time marketing introduces a new payment method (like Apple Pay), you have to modify this function.

class PaymentService {
    func processPayment(type: String){
        if type == "CreditCard" {/* process card */}
        else if type == "PayPal" {/* process paypal */}

    }
}

✅ Do this

Define a protocol. To add a new payment method, just create a new struct/class that conforms to it.

protocol PaymentMethod {
    func pay()
}

class ApplePayPayment: PaymentMethod {
    func pay() { /* process Apple Pay */ }
}

class PaymentService {
    // This is closed for modification. It doesn't care how many payment methods you add!
    func process(payment: PaymentMethod) {
        payment.pay()
    }
}

3. Liskov Substitution Principle (LSP)

"Objects of a superclass should be replaceable with objects of its subclasses without breaking the application."

A subclass must fulfill the promises made by its parent class. If a subclass overrides a method but throws a fatalError() because it can't perform that action, you are violating LSP.

❌ Don't Do this

class Bird {
    func fly() { print("Flying...") }
}

class Penguin: Bird {
    override func fly() {
        fatalError("Penguins can't fly!") // App crashes! Violates LSP.
    }
}

✅ Do this

Refactor your hierarchy using specific protocols

protocol Bird { func makeNoise() }
protocol Flyable { func fly() }

class Eagle: Bird, Flyable {
    func makeNoise() { print("Screech!") }
    func fly() { print("Flying high...") }
}

class Penguin: Bird {
    func makeNoise() { print("Honk!") } // No fly() required!
}

4. Interface Segregation Principle (ISP)

"Clients should not be forced to depend upon interfaces that they do not use."

It's much better to have multiple small, specific protocols rather than one giant, "fat" protocol.

❌ Don't Do this

protocol Worker {
    func code()
    func designUI()
}

class iOSDeveloper: Worker {
    func code() { /* coding */ }
    func designUI() { /* I'm bad at this, but forced to implement it */ }
}

✅ Do this

Split them up! You can combine them later using Swift's Protocols Composition & if needed.

protocol Codeable { func code() }
protocol Designable { func designUI() }

class iOSDeveloper: Codeable {
    func code() { print("Coding in Swift") }
}

5. Dependency Inversion Principle (ISP)

"Depend upon abstractions (protocols), not concretes (classes/struct)."

High-level modules (like ViewModels or Presenters) shouldn't care about the low-level details (like URLSession or CoreData). Both should depend on protocols. This is secret sauce for effortless Unit Testing.

❌ Don't Do this

class APIService {
    func getUser() -> String { return "John Doe" }
}

class ProfileViewModel {
    let service = APIService() // Tightly coupled! Hard to Unit Test.
}

✅ Do this

protocol UserServiceProtocol {
    func getUser() -> String
}

class APIService: UserServiceProtocol {
    func getUser() -> String { return "Real User from API" }
}

class ProfileViewModel {
    private let service: UserServiceProtocol

    // Dependency Injection 
    init(service: UserServiceProtocol) {
        self.service = service
    }
}

Now, during Unit Testing, you can easily pass a MockAPIService() instead of hitting the live network!

Summary

Principle	Swift Tool	Main Benefit
SRP	Separation of Concerns	No more Massive View Controllers
OCP	Protocols & Extensions	Add features without introducing bugs
LSP	Proper Inheritance	Safe subclassing without unexpected crashes
ISP	Protocol Composition (`&`)	Clean, lightweight, and specific interfaces
DIP	Dependency Injection	Highly testable and modular code

Wrapping Up

Applying SOLID principles might feel like writing extra boilerplate code at first. But as your iOS app grows, you’ll thank yourself when you can add new features or write unit tests in minutes instead of hours.

Which of these principles do you find the most challenging to implement in your current iOS projects? Let's discuss in the comments below! 👇

If you found this article helpful, don't forget to leave a ❤️ and Happy coding!

DEV Community: alphonse

Keep Spaghetti in the Kitchen, Not in Your Swift Code: Mastering SOLID 🍝

1. Single Responsibility Principle (SRP)

❌ Don't Do this (The "Do-It-All" Class)

✅ Do this

2. Open/Closed Principle

❌ Don't Do this

✅ Do this

3. Liskov Substitution Principle (LSP)

❌ Don't Do this

✅ Do this

4. Interface Segregation Principle (ISP)

❌ Don't Do this

✅ Do this

5. Dependency Inversion Principle (ISP)

❌ Don't Do this

✅ Do this

Summary

Wrapping Up