connectivity, a network monitoring library for Kotlin Multiplatform

Two ways to answer the same question

Connectivity provides network monitoring capabilities for multiplatform projects, and it can monitor connectivity using native APIs on Android and Apple devices, or by making HTTP requests to specified hosts.

Those two mechanisms are genuinely different and the difference matters. The native approach uses the operating system's own view of the network: on Android that is the ConnectivityManager callback system, and on Apple platforms it is the reachability or path monitor. The HTTP approach makes a request to a host you choose and infers connectivity from whether it succeeds.

The native approach is cheaper and reacts faster, because the OS tells you when the interface changes without you polling. The HTTP approach is portable, because it works anywhere you can make a request, and it answers the question you actually care about: can I reach this server. Those differ, and they differ in a way that produces bugs. A device can be attached to a wifi network that has no route to the internet, in which case the OS says connected and the HTTP check fails. A server can be down while the device is on a working network, in which case the OS says connected and the HTTP check also fails, but for a completely different reason.

The library offers both, and the artifact split is how you choose. The table in the README shows connectivity-core available on every platform including js and wasm, connectivity-device on the mobile and desktop platforms but not on the JVM or in the browser, connectivity-android and connectivity-apple for the native pieces of those two, and connectivity-http everywhere.

The Compose variants follow the same pattern, with connectivity-compose covering Android, iOS, the JVM and js and wasm but not macOS or tvOS, and the device and http Compose variants narrowing further still. The reason the Compose artifacts are narrower is that the native implementation of each has to be written per platform family, and Apple covers iOS, macOS and tvOS as one implementation while the others are separate.

So the design is a common core with pluggable mechanism implementations, and the choice of artifact is the choice of mechanism.

The artifacts and how to add them

The dependency coordinates are all under dev.jordond.connectivity, and the setup section shows the version catalog form for the full set:

[versions]
connectivity = "2.2.1"

[libraries]
connectivity-core = { module = "dev.jordond.connectivity:connectivity-core", version.ref = "connectivity" }
connectivity-device = { module = "dev.jordond.connectivity:connectivity-device", version.ref = "connectivity" }
connectivity-android = { module = "dev.jordond.connectivity:connectivity-android", version.ref = "connectivity" }
connectivity-apple = { module = "dev.jordond.connectivity:connectivity-apple", version.ref = "connectivity" }
connectivity-http = { module = "dev.jordond.connectivity:connectivity-http", version.ref = "connectivity" }

The pattern is worth reading carefully. You always take connectivity-core, and then you add the artifact for the mechanism you want. To use the native API on Android you take connectivity-device plus connectivity-android, because the device artifact holds the shared contract and the platform artifact holds the implementation. The same applies on Apple with connectivity-apple.

For a single platform project, the README shows the direct form:

dependencies {
  implementation(libs.connectivity.core)
  implementation(libs.connectivity.android)

  // For compose support
  implem

The setup section is split into three headings, single platform, multiplatform device, and all supported platforms, which reflects the three sensible configurations. A single platform project takes the core plus one platform artifact. A multiplatform project that wants native monitoring on mobile takes the device artifact, which resolves to the right implementation per target through Gradle metadata. A project that wants the HTTP mechanism everywhere takes the http artifact instead.

That last arrangement is the interesting one for shared code, because a library that targets both Android and the JVM has no native API to use on the JVM, and the HTTP artifact is the only mechanism that works on both.

The artifacts are on Maven Central under the dev.jordond.connectivity namespace, and the KDoc is generated and published at connectivity.jordond.dev, which is the reference to read rather than the README.

Choosing between the native and HTTP mechanisms

The choice between the two mechanisms is the decision the library leaves to you, and it is worth setting out the failure modes because they are different.

The native path asks the operating system. On Android that means the ConnectivityManager callbacks, and on Apple platforms it means the system's own reachability monitoring. The advantages are that it costs nothing while idle, it reacts to interface changes as they happen rather than on a timer, and it does not generate traffic. The disadvantage is that it answers a question you did not ask. The operating system knows whether an interface is up and whether it has an address, and it reports the device as connected to a wifi network in a hotel that has no route to the internet.

The HTTP path asks the question you care about. It makes a request to a host and treats a response as proof of connectivity. That means it correctly reports a device on a captive portal network as offline, and it correctly reports a server that is down as unreachable, which is usually the more useful signal for an application. The costs are the traffic, which is small if you poll a cheap endpoint, and the dependence on the host you chose.

The two also disagree about what a failure means, and that matters when you present the result to a user. A native failure means the network went away. An HTTP failure might mean the network went away, or that your server did, or that a captive portal intercepted the request. A library that only says connected or disconnected cannot tell those apart, and neither can this one.

There is a middle option the README does not spell out but the design allows. Run the native monitor to know when to bother checking, and the HTTP check to know whether your service is actually reachable. The native one becomes a trigger rather than the answer, which removes most of the polling cost while keeping the semantics of the HTTP result.

The polling interval is the other thing you choose, and the trade-off is the usual one. A short interval notices an outage quickly and generates more requests. A long one is cheaper and makes the application feel stale. For a UI indicator, a few seconds is usually enough, and it is worth remembering that the requests go out even when the user is not looking.

Usage, the Compose layer and the target platforms

The usage section is split into options, HTTP monitoring, Compose and multiple targets, and the Compose and multiple target sections are the ones that show how the library is meant to be used.

The Compose integration is what makes the library pleasant in a modern Android or iOS app, and the pattern is the one you would expect: the connectivity state becomes a Compose state, so the UI recomposes when it changes. The device and http Compose variants exist as separate artifacts so you get the mechanism you chose rather than a default.

The multiple targets section is the Kotlin Multiplatform part, where a common module declares the dependency and each platform module gets the right implementation. That is what the device artifact is for, and it is the reason the library splits at all: without the split, a common module would have to depend on a platform implementation that does not exist for its targets.

The HTTP monitoring section is the one that needs the most thought from the user, because it depends on a decision the library cannot make for you. Which host do you poll. A reliable public host tells you about the internet in general, while a host you care about tells you about your own service. Polling a public endpoint is the conventional choice and is usually the right one for a general connectivity indicator, but it means the check has a third party's uptime in it.

There is also a question of what the HTTP check considers a failure. A server that returns a 500 is reachable, and a server that returns a 404 is reachable, so both of those should count as connected if the point is reachability, and only a timeout or a connection failure should count as disconnected. A naive check that treats any non-2xx as a failure will report a healthy server as offline.

The demo section in the README shows a working example for each mechanism, and the repository has a badge for the generated KDoc so you can see the API surface before committing to it.

On maintenance, the releases are frequent: 2.5.1 in August 2026, 2.5.2 later that month and 2.5.3 in October, with the last push on 2026-10-15. The project is built with Kotlin 2.3.0, has a CI workflow, and is MIT licensed.

Editorial conclusion

Adopt connectivity if you are writing Kotlin Multiplatform code and need one connectivity API that works on Android, iOS, desktop and the JVM. Skip it if you only target Android, where the platform's own ConnectivityManager callback is a few lines, or if you need to measure quality rather than reachability. Verify first by adding the core artifact plus the device artifact for your platform, then compare its result against the platform's own network status when you toggle the connection, because the two can disagree about what counts as connected.

Frequently asked questions

Official sources

1. jordond/connectivity on GitHub
2. License: MIT
3. Project website
4. README
5. Releases