Swinject VS Resolver

DI is a concept which makes a class independent of its dependency management. It achieves that by decoupling the usage of an object from its creation. This helps you to follow SOLID’s dependency inversion and single responsibility principles. To achieve this in Swift one of the most appreciated library is Swinject. This library not only provides DI but also have many other features like:-

Swinject - Dependency injection framework for Swift. Language: Swift.

We use Swinject which is probably quite similar https://github.com/Swinject/Swinject

So, how do we fix this? There is a cleaner solution. By using a dependency injection framework, such as Swinject we can create a base module that we might call the DI module.

If you're looking in to using a framework instead of doing it manually, I prefer Resolver over Swinject but both will work.

But, today, I use Resolver. And recommend others also use this. There are other approaches, but Resolver is quite good. It solves this problem. "Just pass stuff in to the constructor" isn't true dependency injection anyway (but it kinda works, it's just a huge mess).

You can achieve the concept as the environment in SwiftUI using protocols and Resolver https://github.com/hmlongco/Resolver

This isn't a full tutorial, but it's a great Swift dependency injection library with lots of information in its documentation: https://github.com/hmlongco/Resolver

I also suggest Resolver

Sounds ok, and for DI I can recommend this lib, works well and easy to use https://github.com/hmlongco/Resolver/

We’re using Resolver for dependency injection. Check it out: https://github.com/hmlongco/Resolver

Since multiple ViewModels need to access this data, I would avoid storing the data in a particular ViewModel—which should correlate only with a single, specific View—and instead implement this behavior in a third object (such as an AuthenticationService class). This way, both/any of your subsequent Views and ViewModels alike can all access that object as a single source of truth (by passing it around explicitly, putting it in the environment, or my favorite method: Resolver). Just remember to think about who should “own” data!