The issue with Koin is, that it’s not really a dependency injection framework, but rather a service locator. With dagger, if there’s an issue with your dependency injection setup, such as circular dependencies, injecting from the incorrect module, etc, all these problems will pop up during build time. With Koin (and all the other service-locator types of frameworks), you’ll only ever get an error during run time, and even then, only if you’re lucky enough to execute that part of the code during development/testing.

Pros and cons to everything, right?

Also, I would argue, that using the most trivial example, Dagger actually brings much LESS boilerplate than Koin, because technically speaking for trivial cases in Dagger you can get away with not writing any module whatsoever, or maybe just one module for all the `Activities` and `Fragments`, with Koin, you really need to write some boilerplate for EVERY class that you want to inject somewhere else. With Dagger, you just write @Inject annotation and that’s it.

I think lot of these opinions about how dagger requires much more boilerplate stem from the fact, that it’s a rather complex tool and learning curve is really steep and it’s easy to make a mistake and really hard to find out how to avoid all the boilerplate (many examples online include a lot of boilerplate code, because they tend to focus on the more sophisticated cases rather than the simple ones).