Stop Using Dependency Injection for your iOS Project

It’s not always the right answer!

Steven Curtis
2 min readApr 30


Photo by Michael on Unsplash

I’ve written a few articles about Dependency Injection, and this often seems to me to be the go-to solution for iOS developers.

Does it actually solve all the problems we’ve ever had in iOS development? Let us read on to find out!

A solution to a problem?

Dependency Injection is a solution to an problem. If you don’t know what the problem is, how do you know that you are picking the right solution?

Within the SOLID acronym D is The Dependency Inversion Principle.

This is a principle that allows the decoupling of software modules. That is to say:

- High-level modules should not depend on low-level modules. Both should depend on abstractions
- Abstractions should not depend on details. Details should depend upon abstraction — that is the protocol in this case

Methods to solve this problem are ServiceLocator, Event, Delegate.

Each potential problem in turn

Too many dependencies

If there are too many dependencies, can they be removed?

If you can successfully move all dependencies then dealing with those dependencies becomes a mute point.

Swapping mocks in and out

We always need to be careful when testing against mock implementations. If you test module A against module B's mock and never against production module B there is a chance of side effects and the application will not work in production.

You are effectively testing the contract between A and B and risk using simplified mocks to do so, rather than real outputs. Tread with care!

Problems that Dependency Injection can introduce


It is possible that Dependency Injection adds more complexity to your code If you are using interfaces, extra classes and mocks (remember, please add these to the test target).