Can anyone guide me on how DI should be handled in KMM projects? In the shared module, I’ve created my usecase that is dependent on a repository object (also repository is dependent on other objects). I use Koin in android and shared module and everything works well. But in iOS I don’t have any idea how to inject the repository into the usecase.

Our team is going to run into this soon as well, we're hoping to learn from the KaMPKit project: https://github.com/touchlab/KaMPKit/blob/main/ios/KaMPKitiOS/Koin.swift

There is a koin channel here and just this morning I asked the same question, no response yet

fwiw am using Koin for shared code in https://github.com/joreilly/PeopleInSpace

@John O'Reilly thank you. Your solution helped me. @Tiago Nunes & @Rak I suggest you to check it out too. Also this article could be useful https://johnoreilly.dev/posts/kotlinmultiplatform-koin/

@Hossein Amini My 2 cents, I use Koin for the shared module and Hilt for androidApp. Why two? Well first I wanted to try if it was possible, in theory since one is compile time and other run time, it shouldn’t be a problem. Second, I prefer Hilt over Koin. So far so good, no problem found.

@Guilherme Delgado I didn’t know that’s possible 🤔 On the iOS, is it possible to use native DI libraries to inject my use-cases too?

Me neither, that’s why I’ve tried and was happy with the result ^^ You don’t have to, just setup your koin dependencies receiving their parameters as field injection instead of constructor injection and you’re good to go (for shared instances)

@Guilherme Delgado how are you injecting dependency from shared code in to say android vm etc if mixing di frameworks like this?

Ok let me share my logic: module shared/… Di setup:

// called by iOS etc
fun initKoin(enableNetworkLogs: Boolean) = initKoin(enableNetworkLogs) {}

fun initKoin(enableNetworkLogs: Boolean = false, appDeclaration: KoinAppDeclaration = {}) =
    startKoin {
        appDeclaration()
        modules(commonModule(enableNetworkLogs = enableNetworkLogs))
    }

private fun commonModule(enableNetworkLogs: Boolean) = module {
...
    single { SettingsApi(get(), PlatformDependencies().baseUrl) }
    single { SettingsManager() }
}

Classes:

class SettingsManager: KoinComponent {

    private val api: SettingsApi by inject()
    ...
}

class SettingsApi(private val client: HttpClient, private val baseUrl: String) : KoinComponent {...}

shared/androidMain:

...
lateinit var buildConfigApiUrl: String

actual class PlatformDependencies actual constructor() {

    actual val baseUrl: String = buildConfigApiUrl

    ...
}

module androidApp/…

class App : Application() {

    override fun onCreate() {
        super.onCreate()
        ...
        buildConfigApiUrl = BuildConfig.API_URL
        initKoin(BuildConfig.DEBUG) {
            androidLogger()
            androidContext(this@App)
        }
    }
}

Di setup:

@Module
@InstallIn(SingletonComponent::class)
object AppModule {

...

    @Provides
//    @ViewModelScoped
    @Singleton
    fun provideSettingsManager() = SettingsManager()
}

@HiltViewModel
class MyViewModel @Inject constructor(
    private val settingsManager: SettingsManager,
    ...
) : ... {

@John O'Reilly Please feel free to comment and validate, this was something that I wanted to bring into discussion. It’s working, but maybe I’m getting here a false positive or it works in this specific use case 😉

ok, so

SettingsManager

is being separately managed as dependency in both Hilt and Koin?

I would say yes. Actually in the shared module no one calls SettingsManager directly so this: 

single { SettingsManager() }

 ends up being the iOSApp DI setup. 🤔

yeah, and also just having an extra library dependency to manage like this has some overhead....I had started using Hilt in one repo I had, but reverted to Koin as I was seeing too many issues as I moved though Compose updates

well so far I haven’t experienced this kind of issues (even with compose updates), but sure the compile time will have overhead and also managing two DI libs.

I initially ran in to following but was able to use workaround https://github.com/google/dagger/issues/2631

since this are small POC projects so far so good. But if I had to use in PRD I guess I would go full Koin.

I had used that approach while we needed Canary for Compose but once it was available in beta then I switched to that so that could take advantage of AS tooling etc

dunno if it kept me away, and also the buildtools were 4.2.1

@Hossein Amini yes I'm using needle by User for my IOS code atm