koin VS Kodein

Building UIs with Compose Multiplatform is getting more and more popular. If you're looking for a solid way to structure your app, you might have heard of Circuit from Slack for UI architecture and Koin for dependency injection. They work great together!

Koin - Dependency injection

In the Kotlin ecosystem, dependency injection (DI) frameworks are essential for managing dependencies, improving modularity, and streamlining application development. Koin has emerged as a popular DI framework for Kotlin developers, especially valued for its simplicity, lightweight nature, and multiplatform support. At the time of writing, Koin 4.0 has been released. Built on Kotlin 2.0, this release introduces a wide range of enhancements and Compose Multiplatform features. As we move into 2025, Koin continues to be an excellent choice, particularly because of its Kotlin-first design, ease of use, and adaptability across platforms.

The Koin framework is now updated to support the latest Kotlin version, now integrating with Google KSP. Koin Annotations 2.0.0-Beta1 to take advantage of Kotlin 2.0.20 and KSP 2.0.20-1.0.25, and target Koin 4.0. This release is based on the stable 1.4.0 version.

Added Koin as Dependencies Injection framework

Koin to manage dependency injection (more explanation about that later)

Let's see how we can use Koin to achieve Dependency Injection (DI) and incorporate a third-party iOS Swift SDK in a KMM project. Koin supports KMM development, making it the ideal choice for KMM projects.

Now I will finish up saying Hilt is just an opinionated way to dependency injection on Android, but there are simpler frameworks out there such as Koin or Kodein that can help take away a lot of the troubles that can come when you try to make your own framework. Just know that most other frameworks tend to be runtime injection instead of compile time injection like Hilt, which can be helpful to know at compile time if you are missing a dependency in your graph as opposed to runtime when its out in the wild.

Long answer: My pain mostly comes from using [Kodein](https://github.com/Kodein-Framework/Kodein-DI/) and a custom service locator in an iOS/Swift project. Other than that I have very little experience with DI (e.g. I never used Dagger so far), so my opinion might be a little biased. Also, both of these projects are really large, so, in many cases, a class is declared in one module but used in a completely different module and the DI or service locator is sort of the glue between the modules.