Why Koin

[ryansgot]

Hi. My question is specifically regarding why this project is tightly coupled to Koin. While koin can be used as a dependency injection system that works with KMP, it should not be necessary to setting up the object graphs/factories necessary for this library, and it would make this library more accessible for other library authors (who don't want their libraries to be transitively dependent upon koin). Are there any plans to remove it?

[vietnguyentuan2019]

You're right, and it's already fixed on a branch.

How it got here: Koin wasn't a design decision, it was inheritance. This started as a Compose Multiplatform demo app that used Koin for its own DI. When the background-task code was extracted into a publishable module (v2.1.0), the KoinModule.kt trio came along with it. Then v2.2.2 fixed the worst symptom — the library called global startKoin, which crashed any host app that already had Koin — by switching Android to a private isolated koinApplication. That fixed the crash but only on Android, which is why the coupling you hit is lopsided.

You're right on the facts. I checked the published 3.2.0 metadata rather than answering from memory: koin-core:4.0.0 at runtime scope in the root and iOS .module files, plus koin-android in the -android POM. And on iOS kmpWorkerModule() was the only documented init path while being declared expect fun ...: org.koin.core.module.Module — a public function returning a type from an implementation-scoped dependancy, so you had to declare koin-core yourself just to call it. That's an API defect, not a preference.

Removal turned out cheap. The module used no container feature — no scopes, no qualifiers, no lazy graph. Everything meaningful ran at module-construction time and every wired class was already public. It's now a plain internal registry of by lazy singletons.

Landing in 3.3.0, not a 4.0.0 as I first sketched — deprecating kmpWorkerModule() wouldn't remove anything, since it's an expect fun in commonMain, so core would keep implementation(koin-core) and the POM wouldn't shrink. It goes out in one release instead:

• iOS gets KmpWorkManager.initialize() mirroring Android's, keeping the eager Info.plist BGTask validation
• kmpWorkerModule() deleted; koin-core leaves the POM entirely
• no bridge artifact — if you want Koin, single { KmpWorkManager.getInstance().backgroundTaskScheduler } in your own module is the whole migration

#67 drops koin-android first (it was dead — only transitively supplying androidx.core); the main work is on feat/issue-66-koin-free-init.

Porting the wiring also surfaced a real bug: on iOS, EventStore and ExecutionHistoryStore were lazy single { } bindings whose global-registration side effects only ran if something resolved them — and nothing in the library or the sample ever did. So unless you explicitly pulled them out of Koin yourself, TaskEventManager was never wired and getExecutionHistory() returned empty. Android had it right via createdAtStart. Both are eager on both platforms now.

Thanks for pushing on this — it's the kind of thing that only gets fixed when someone outside the project asks.

[ryansgot]

Thanks for answering the question. It would be great to use this library. My team has tested it, and it works for our purposes--just has the one negative side-effect mentioned above. I'm glad you're working on decoupling koin. Any idea on when a new version will be published?

[vietnguyentuan2019]

Shipped in v3.3.0.

kmpWorkerModule() / kmpWorkerCoreModule() are removed. KmpWorkManager.initialize() is now the entry point on both platforms — no Koin, no DI framework required. Koin/Hilt users bind KmpWorkManager.getInstance() from their own module (see docs/MIGRATION_V3.3.0.md).

Confirmed against the actual published metadata this time, not just the source: koin-core/koin-android are absent from every .pom/.module in the release bundle — root, -android, -http, and all three iOS klib variants.

Two things worth knowing if you're upgrading:

• Porting the wiring off Koin surfaced a real bug: on iOS, EventStore/ExecutionHistoryStore were never resolved by anything in the library, so execution history was silently empty and shutdown() → re-initialize() could leave stale global state. Both fixed in 3.3.0.
• Filed #71 for a narrower, separate gap found along the way: iOS single (non-chained) tasks still don't persist events/history the way chains and Android do. Not part of this fix — tracked on its own.

Thanks again for pushing on this.

[ryansgot]

Thanks, @vietnguyentuan2019 . I will check and attempt to integrate this on Monday.