Home / dependency injection iOS interview
Architecture
Dependency injection iOS interview
Dependency injection comes up across coding, testing, and architecture rounds because it is the mechanism that makes code testable. Interviews want the practical version, not jargon.
What DI actually is
Dependency injection means a type receives its collaborators from outside rather than constructing them itself, usually through its initializer. Depending on a protocol rather than a concrete type creates a seam where you can inject a real implementation in production and a fake in tests, which is what makes behavior verifiable without network, disk, or time.
Applying it on iOS
Prefer constructor injection for clarity, falling back to property or environment injection where a framework requires it. In SwiftUI, the Environment can pass shared dependencies down the tree. Discuss avoiding a global singleton as a hidden dependency, and that a container or factory can wire graphs, though for most apps plain initializer injection is enough.
Go deeper than a summary
Share Your Screen works topics like this through in full: 75 solved Swift problems with tests, 9 real case studies, and 7 annotated mock interviews, so you rehearse the live round instead of just reading about it.
Frequently asked
Why does DI matter for testing?
It lets a type depend on an abstraction so you can inject a fake in tests, verifying behavior without real network, disk, or time dependencies.
What is the simplest form of DI in Swift?
Constructor injection: pass a type's collaborators, ideally as protocols, into its initializer instead of creating them inside the type.