Why Dependency injection in iOS Swift? - Purpose & Use Cases

The Big Idea

Discover how handing over your tools can make your code smarter and easier to manage!

The Scenario

Imagine building an app where every part creates its own tools and helpers inside. For example, a screen creates its own network manager and database handler directly.

The Problem

This manual way makes your code tightly connected and hard to change. If you want to swap the network manager or test the screen, you must dig deep and rewrite many parts. It's like having a tangled ball of yarn that's tough to separate.

The Solution

Dependency injection hands the needed tools to each part from outside. Instead of creating them inside, parts receive what they need. This keeps code clean, easy to swap, and simple to test.

Before vs After

✗ Before

class Screen {
  let network = NetworkManager()
  // uses network directly
}

✓ After

class Screen {
  let network: NetworkManager
  init(network: NetworkManager) {
    self.network = network
  }
  // uses injected network
}

What It Enables

It enables flexible, testable, and maintainable code by separating creation from usage.

Real Life Example

Think of a coffee shop where the barista gets coffee beans delivered instead of growing them. The barista focuses on making coffee, while the beans can come from any supplier.

Key Takeaways

Manual creation leads to tightly coupled code.

Dependency injection separates creation from use.

This makes code easier to change and test.

Practice

1. What is the main purpose of dependency injection in Swift programming?

easy

A. To provide objects with their dependencies from outside rather than creating them inside

B. To make the app run faster by caching data

C. To automatically generate user interfaces

D. To encrypt data before saving

Solution

1. Step 1: Understand dependency injection concept

   Dependency injection means giving an object the things it needs (dependencies) from outside instead of creating them inside the object.

2. Step 2: Identify the main purpose

   This approach helps keep code flexible, easier to test, and cleaner by separating concerns.

3. Final Answer:

   To provide objects with their dependencies from outside rather than creating them inside -> Option A

4. Quick Check:

   Dependency injection = provide dependencies from outside [OK]

Hint: Dependency injection means giving dependencies from outside [OK]

Common Mistakes:

• Thinking it speeds up app performance
• Confusing with UI generation
• Mixing with data encryption

2. Which of the following is the correct syntax for constructor injection in Swift?

easy

A. class Client { func inject(service: Service) { self.service = service } }

B. class Service { init() { } } class Client { let service: Service; init(service: Service) { self.service = service } }

C. class Client { var service = Service() }

D. class Service { func start() {} }

Solution

1. Step 1: Identify constructor injection pattern

   Constructor injection means passing dependencies through the initializer (init) of a class.

2. Step 2: Check which code passes dependency via init

   class Service { init() { } } class Client { let service: Service; init(service: Service) { self.service = service } } shows a Client class receiving a Service instance through its init method and storing it.

3. Final Answer:

   class Service { init() { } } class Client { let service: Service; init(service: Service) { self.service = service } } -> Option B

4. Quick Check:

   Constructor injection uses init to pass dependencies [OK]

Hint: Constructor injection passes dependencies via init method [OK]

Common Mistakes:

• Creating dependencies inside the class instead of passing them
• Using methods instead of init for injection
• Not storing the injected dependency

3. Given the code below, what will be printed?

protocol Logger { func log(_ message: String) }
class ConsoleLogger: Logger { func log(_ message: String) { print("Console: \(message)") } }
class Client {
  let logger: Logger
  init(logger: Logger) { self.logger = logger }
  func doWork() { logger.log("Work done") }
}
let client = Client(logger: ConsoleLogger())
client.doWork()

medium

A. No output

B. Work done

C. Console: Work done

D. Logger: Work done

Solution

1. Step 1: Understand the Logger protocol and ConsoleLogger class

   ConsoleLogger implements Logger and prints messages prefixed with "Console:".

2. Step 2: Trace the Client usage

   Client is initialized with ConsoleLogger and calls logger.log("Work done"), which prints "Console: Work done".

3. Final Answer:

   Console: Work done -> Option C

4. Quick Check:

   Injected ConsoleLogger prints with "Console:" prefix [OK]

Hint: Injected logger prints message with prefix [OK]

Common Mistakes:

• Ignoring the prefix in print statement
• Assuming no output because of protocol
• Confusing method names

4. Identify the error in the following Swift code using dependency injection:

protocol DataService { func fetchData() -> String }
class RealDataService: DataService { func fetchData() -> String { "Real Data" } }
class ViewModel {
  var dataService: DataService
  init() { }
  func load() -> String { dataService.fetchData() }
}

medium

A. dataService is not initialized before use

B. fetchData() should return Int, not String

C. ViewModel should not have an init method

D. RealDataService does not conform to DataService

Solution

1. Step 1: Check property initialization

   ViewModel has a non-optional property dataService but its init() does not initialize it.

2. Step 2: Understand Swift initialization rules

   Non-optional properties must be initialized before use; missing initialization causes a compile error.

3. Final Answer:

   dataService is not initialized before use -> Option A

4. Quick Check:

   Non-optional properties must be initialized [OK]

Hint: Non-optional properties must be set in init [OK]

Common Mistakes:

• Assuming default nil for non-optional
• Confusing return types
• Ignoring protocol conformance

5. You want to make a Swift class NetworkManager testable by injecting a protocol NetworkService. Which approach best applies dependency injection and allows easy swapping of real and mock services?

hard

A. Create NetworkManager with a fixed real network service inside the class

B. Make NetworkManager inherit from NetworkService and override methods

C. Use global variables to hold the network service instance

D. Define a NetworkService protocol, make NetworkManager accept it via init, and pass either real or mock implementations when creating NetworkManager

Solution

1. Step 1: Understand testability with dependency injection

   To test NetworkManager easily, inject a protocol so you can swap real and mock implementations.

2. Step 2: Identify best practice

   Passing NetworkService via init allows NetworkManager to use any implementation, making testing flexible.

3. Final Answer:

   Define a NetworkService protocol, make NetworkManager accept it via init, and pass either real or mock implementations when creating NetworkManager -> Option D

4. Quick Check:

   Inject protocol via init for flexible testing [OK]

Hint: Inject protocol via init to swap real/mock easily [OK]

Common Mistakes:

• Hardcoding real service inside class
• Using global variables causing tight coupling
• Misusing inheritance instead of composition