koin VS Decompose

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.

Might want to tell koin that : https://insert-koin.io/

New modules allow you to easily build KVision apps with the Ballast opinionated application state management framework. You can see how Ballast (together with Koin) can help you design your application architecture in the new todomvc-ballast example.

I started looking into using Kotlin/JS, and hopefully reusing a bit of code that I have, which is using Dagger and Anvil - which of course are JVM only. So I've been looking for other solutions, namely Koin and Kodein. Koin's multibinding support is... not really amazing (e.g. here, and while Kodein does support multibinding, it doesn't seem to support things like that at the declaration site - everything needs to be specified in a "DI container" (module).

Koin

It's a Koin issue, not compose. Discussed here https://github.com/InsertKoinIO/koin/issues/1079

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.

I've been using Angular a lot and I like how it works. I'm also a huge fan of koin for kotlin.

for injection, I suggest Koin (https://insert-koin.io/)

I use Decompose, although I also have a kmp project which that supports. I find the compose extensions providing a very easy API when integrating with compose.

For one of our apps we used https://arkivanov.github.io/Decompose/ for navigation. It is mentioned in the Compose Multiplatform repo, but we found it pretty obscure to use and it has some confusing concepts built in.

View model is Googles recommended approach, but there are other approaches out their you can use like decompose

When you are building your app in KMM, sometimes you need to pack some libraries along with project files in the shared module. For example if you are using Decompose you need to access it's Value class in Swift.

I don't have much experience with conductor, so I'm curious what your concerns about lifecycle is lacking compared to fragments? But if your team already knows that framework I might just stick with views over fragments. I see there is a compose integration if you do ever plan on picking that up with conductor. Otherwise compose makes fragments obsolete and your team already knows conductor. I do agree the navigation story in compose is not mature especially after jetpack compose navigation. But there are other 3rd party libraries like compose destinations or decompose, but would be nice to see something better 1st party.

I personally like decompose for its testability, clear separation of concerns, and apis for compose animations. Plus it's multiplatform so you can use it for other kmp targets.

Full discretion, all my new apps are built using mvi with MVIKotlin and decompose for the compose extensions for navigation animations. A sample project I have built with that architecture can be found here.

Check out Decompose, it's multiplatform - https://github.com/arkivanov/Decompose

Decompose