With HILT being publicly endorsed by google as the recommended DI framework, and dagger getting some key new features this year like assisted injection. Is there any reason to continue using Koin / Kodein for android? If you have multiplatform ambitions for your existing codebase, how might you approach DI?

I'm not a big fan of Dagger. Koin (and I think Kodein) have been updated for multiplaform. I really like the simplicity of Koin

Not Kotlin but main reason is compile time. Dagger/Kapt destroys build times

Yeah i guess questions about Kotlin dependency injection in Android is 😶 🤷

DI vs service locator is a :canofworms. I think ppl should use whatever solution that helps them achieve their goals

Compile time validation is just an incredible huge advantage of dagger, even with all compile time issues

I would say: If you have multiplatform ambitions for your codebase, then you should use a multiplatform DI framework. I worked a bit with Kodein and it is very nice, but indeed the compile time errors are a big (and obvious) miss. However, the lack of code generation makes the framework much more transparent and easier to understand. I found that scoping was much easier there, so it is harder to mess up scoping with Kodein than with Dagger. There are mentions of a compiler plugin DI framework (just the idea of it) as one of the many things we can use compiler plugins for, and I did get the notion that jetbrains was brainstorming about providing such a solution (or perhaps it was just an idea they want the community to work on) so we can be hopeful that one day we can have a multiplatform compile time dependency injection framework. 🙂 and a note: I do consider your question very Kotlin-worthy, in a Kotlin world with developing an Android app in Kotlin, should I use a Kotlin dependency injection framework with an eye on Kotlin Multiplatform or not 🙂

dagger works with multiplatform, you just reuse platform specific di

@gildor why do you need KSP for multiplatform dagger? Kapt can generate code on jvm but this code can then be used on different platforms. Is there something more that dagger does which can't be achieved with kapt?

Kapt doesn't generate code (except stubs, which a hack to make Kotlin compatible with Java APT), Kapt allows you read declarations on compile time You are right, you can generate some code and then use it in common code, but it always very limited solution, you cannot read any declarations in common code, only in JVM project In case of dagger, first of all it doesn't generate Kotlin code, it generates java and it highly coupled with your code declarations to generate code, you just cannot run it on non-jvm project, so moving to ksp as first step has much better perspective: makes compilation faster for Kotlin projects and because it doesn't depend on Java APT, it can read any Kotlin code, and next step may be to generate multiplatform Kotlin Though, all those steps require a lot of work on side of Dagger

Makes sense, thanks for explaining :)

You can do this in shared module, but not all code is shared, you have platform specific code, so dagger just not able to generate providers or factories for it. I do not say that it completely impossible, there is chance that you just apply java plugin to common/platofrm code and it will work, so kapt will work too, but I doubt that it practical solution, most of the time it will just fail on every non-jvm annotation (even kotlin stdlib is not the same for different platforms). And again, now for dagger it’s pointless, it’s anyway generates Java

time for

kagger

😆?

There are a few experiments in this direction, one which I like the most is this: https://github.com/evant/kotlin-inject But it’s not MPP (but it may be, when KSP will support MPP)

kotlin-inject

looks like it was def inspired by dagger. I think challenges is you lose some of the integrations like dagger-hilt

I use koin for my multiplatform and there's bunch of things which are platform specific. E.g. you have a common media player manager with some common logic but then you have a platform specific impl of the player and you inject different things on ios and on Android for that.

Does the rest of the iOS app utilize Koin as well?

no, shared uses koin internally and then exposes a module which is consumed on ios with swinject