Over the past decade of building Android libraries, I’ve realized they differ not just by what they do, but by how tightly they’re coupled to the Android OS.

When designing or choosing a library today, understanding this level of coupling is crucial. Historically, libraries fell into two buckets. Thanks to Kotlin Multiplatform (KMP), we now have a clear third category.

Through my own experience, I’ve found it helpful to group these libraries into three main categories, ranked from ‘deeply Android’ to ‘completely platform-agnostic.

1. Android Dependent

These libraries are deeply dependent on the Android OS. They rely on native lifecycles, hardware APIs, Context, system services, or other Android-only functionality.

Historically, this category was dominated by UI libraries (because of XML layouts and View system knowledge) and service-style libraries. Therefore, your UI library had to be an “Android library” with Android imports and framework knowledge.

Since UI can now be multiplatform, with libraries like Compose Multiplatform (CMP) empowered by KMP, the UI category of libraries no longer automatically means an Android-only library.

2. Android Context-Independent (Accidental KMP Candidates)

These libraries are written for the Android/JVM ecosystem but don’t actually need Context, lifecycles, or Android system APIs. They typically handle business logic, calculations, data parsing, or architectural patterns.

Because they contain no Android imports, they are “accidental” candidates for Kotlin Multiplatform. They’re already free of Android framework dependencies — they’re just still locked into the JVM by Java-specific classes (e.g. java.util.UUID, java.net.URL, java.time.*, etc.).

Swap those for pure Kotlin equivalents (or kotlinx.* libraries), and you can often turn them into proper multiplatform libraries with minimal effort.

3. Platform-Agnostic (Kotlin Multiplatform)

These libraries are intentionally designed from the ground up (or properly migrated) to run anywhere. Using Kotlin Multiplatform, they compile to Android (JVM), iOS (native), desktop, web, and more.

They rely on pure Kotlin and the kotlinx.* ecosystem instead of platform-specific code.

Functional Areas: Where Common Libraries Fit

Android Dependent

  • Camera, permissions, background tasks, location services, and anything that directly touches hardware or system services.

Context-Independent (Accidental KMP)

  • Dependency injection (e.g. Koin), threading & coroutines, most business logic, validators, parsers, and utility classes.

Platform-Agnostic (KMP)

  • Networking (Ktor), databases (SQLDelight), serialization (kotlinx.serialization), logging, state management, and date/time handling.
  • UI components, animations, and image loading (thanks to Compose Multiplatform).

Hybrid (Shared API + Platform Implementation)

  • Navigation, maps, audio/video playback, localization, and UI testing.
    These usually expose a clean KMP interface while using platform-native engines underneath (ExoPlayer on Android, AVPlayer on iOS, etc.).

Key Takeaway for Library Authors & Integrators

If you’re writing an Android library in 2026, ask yourself one simple question:

Does this code actually need an Android or Java specific import?

If the answer is no, design it as a Context-Independent library from the start. You’ll future-proof your work, make it much easier to adopt Kotlin Multiplatform later, and increase its value to the wider developer community.

The multiplatform era is here. The best time to start thinking platform-agnostic was yesterday. The second best time is today.