Thanks for sharing. I haven't seen this approach to Swift DI before, I like it. I tend to use a central dependency manager approach (sparingly) for dependencies that benefit being switched across the whole project (e.g. injecting a mock API layer for testing), and constructor injection for anything more lightweight. For cases such as view controllers, where constructor injection can't always be used, I've used variable injection. I really hate it, because it makes the API untidy, and sets a precedent for coders coming after to scatter public vars around the place :-). As well as the benefits you outlined, your approach looks like a good way of communicating the intent of variables that are intended for dependency injection, and helping to keep the API tighter.