Dagger may be “better” but we don’t have Dagger for Swift and as such need to do what we can do.

You’re close in what Resolver actually does, but the current implementation of @Injected isn’t lazy and you can set the desired container if you wish. You can also add your own containers to the default resolution path which lets you pretty much mock to your hearts content.

I can (and have) written Injected property wrappers for Resolver, Dip, and Swinject, and as such I feel that the Injected wrapper effectively hides the specifics of a given Service Locator instance and gets us to cleaner software.

And to quote Fowler, “The choice between Service Locator and Dependency Injection is less important than the principle of separating service configuration from the use of services within an application.”

Which is what these systems do. All support “classic” DI concepts and also support SL concepts for those occasions (like UIKit UIViewControllers) where entities are instantiated outside of our control.

In particular, annotation obviates the need to write constructor boilerplate code for every class whose only function is to blindly assign parameter A to property A, parameter B to property B, parameter C to property C, and so on.

Fowler himself notes that drawback in his classic article on the subject.