# Cloud Messaging sits at 5% in the Firebase Kotlin SDK coverage table

> GitLiveApp's Firebase Kotlin SDK exposes Firebase from Kotlin Multiplatform common code by binding to each platform's official SDK. The README publishes a coverage percentage per library, and the spread from 100% to 5% is the most useful thing it contains.

**GitLiveApp/firebase-kotlin-sdk** — A Kotlin-first SDK for Firebase

- Repository: https://github.com/GitLiveApp/firebase-kotlin-sdk
- Website: https://gitliveapp.github.io/firebase-kotlin-sdk/
- Stars: 1,733 · Forks: 199
- Language: Kotlin
- License: Apache-2.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/gitliveapp-firebase-kotlin-sdk

## The coverage column is the honest part of the README

Twelve Firebase products are listed with a Gradle coordinate and a coverage percentage, and those numbers are the argument in the table rather than a footnote.

Installations is complete at 100%. Storage follows at 64%, Cloud Functions at 63%, Crashlytics at 88%, Authentication at 53%, Realtime Database at 48%, Remote Config at 49%, Performance at 35%, Cloud Firestore at 23%, Analytics at 16%, and Cloud Messaging at 5%.

Those percentages are linked to the actual source file for each library, so a reader can go from the badge to the Kotlin file and see what is and is not wrapped. That transparency is unusual in an SDK README and it changes how you evaluate the project. A team planning to use Firestore from common code will find that roughly a quarter of the API surface exists, which is a planning input rather than a disappointment discovered during implementation.

The dependency coordinates follow the same pattern, one artifact per product, all under the dev.gitlive group and pinned to 2.7.0 in the table:

```
dev.gitlive:firebase-analytics:2.7.0
```

The README closes the loop on the gaps with an invitation to open an issue requesting additional coverage, with a template that asks for the class name, the function name, the library name and the platform names.

## How the common API reaches four platforms

The mechanism is a set of bindings rather than a reimplementation. The SDK provides a common API to access Firebase for projects targeting iOS, Android, JVM and JS, and under the hood it binds to the respective official Firebase SDK for each supported platform.

That distinction drives most of the behaviour you will notice. Anything the platform SDK does not expose cannot be in this SDK, so coverage is bounded twice, once by what the wrapper has implemented and again by what the underlying platform library can do. The table shows materially different coverage across libraries, ranging from 5% for Cloud Messaging to 100% for Installations.

The repository layout follows the same structure. There is one Gradle module per Firebase product, firebase-analytics, firebase-auth, firebase-database, firebase-firestore, firebase-functions, firebase-installations, firebase-messaging, firebase-perf, firebase-storage and firebase-crashlytics among them, plus firebase-app, firebase-common, firebase-common-internal for shared infrastructure, and test, test-utils and buildSrc for the build itself. Each coverage badge points into that product's commonMain source set, so the module and the badge describe the same thing.

The intended payoff is stated in the opening paragraph: use Firebase directly from your common source targeting iOS, Android, Desktop or Web, which makes it a backend option for Compose Multiplatform without writing platform branches.

## The JVM target is not the official JVM SDK

One platform behaves differently enough to deserve its own note. For the JVM target the SDK uses the GitLiveApp Firebase Java SDK, and the README states that this library requires additional initialization compared to the official Firebase SDKs.

The JVM target uses the GitLiveApp Firebase Java SDK, which has its own additional initialization requirements. That is a maintenance and compatibility surface of its own: you are depending on a bridge library maintained outside Google, and its initialization contract is not identical to the one you would follow in an Android project.

The initialization section explains why the table has a context argument column and separate columns for behaviour without options and with options. Firebase.initialize is the single entry point for every platform, but what it does, and whether you need to call it at all, depends on how the underlying Firebase SDK is initialised on that platform. In other words, the common code calls one function and each platform target interprets it differently.

That is the kind of design that works well when it works and confuses people when it does not, so the table is worth reading before you write the first call rather than after.

## 2.7.0 is stable and 3.0.0 is in alpha

The release list shows two lines in flight. Version 2.7.0 was published on 2026-09-02, and the alpha line follows it with 3.0.0-alpha01 on 2026-08-05 and 3.0.0-alpha02 on 2026-09-03.

The ordering matters when you pick a version. The alpha tags came out before the 2.7.0 stable tag, which is normal for a project doing a major version bump, but it means 3.0.0-alpha02 is the newest artefact by date and not the one the README's dependency table shows. Every coordinate in the table is pinned to 2.7.0.

So the default recommendation is the 2.x line, and the 3.x alphas are for testing a major version migration. Nothing in the visible README describes what breaks between them, so anyone moving should read the release notes on GitHub rather than assume the 2.x API carries over.

The last push was on 2026-10-15, so the project is being worked on actively, and the licence is Apache-2.0 with the documentation published at gitliveapp.github.io/firebase-kotlin-sdk.

## Where this SDK is the wrong choice

Three situations argue against it.

An Android-only project should weigh the extra abstraction of this multiplatform wrapper against using Firebase directly for that platform.

If your common module needs Cloud Messaging, the coverage table is the argument against: its 5% coverage signals substantial missing API coverage. Push notifications are typically a platform-specific feature anyway, since delivery on iOS and Android goes through different native paths, so the shared code would rarely own that logic.

If your team cannot tolerate an SDK that is a coverage project rather than a finished product, the percentages across the board are the reason. Firestore at 23% and Analytics at 16% mean that a feature which looks like one line of common code may not exist at all, and discovering that during a sprint is more expensive than discovering it in a planning table.

The common thread is that the binding layer only earns its keep when the same Firebase call is genuinely needed from iOS, Android, Desktop and Web. Below that threshold it is an abstraction you pay for and do not use.

## Conclusion

The Firebase Kotlin SDK fits a Compose Multiplatform project whose shared code touches Firestore, Storage or Authentication, where the binding layer removes platform branches from your business logic. It does not fit a team that needs Cloud Messaging, since the README puts that library at 5% coverage, and it will not help a plain Android project that already has the official Kotlin extensions. Before adopting, compare the coverage column against the specific Firebase calls your common module makes, because a dependency that compiles is not a dependency that is finished.

## FAQ

### Which platforms does the Firebase Kotlin SDK support?

It provides a common API for projects targeting iOS, Android, JVM and JS, by binding to the official Firebase SDK for each supported platform. The README frames it as a way to use Firebase as a backend for Compose Multiplatform.

### Which Firebase libraries are fully supported by the Kotlin SDK?

Installations is the only one listed at 100%. Storage is at 64%, Cloud Functions at 63%, Crashlytics at 88% and Authentication at 53%. Cloud Messaging is the lowest at 5% and Cloud Firestore sits at 23%.

### How do I add a Firebase product to a Kotlin Multiplatform project?

Each product is a separate Gradle dependency under the dev.gitlive group, for example `dev.gitlive:firebase-analytics:2.7.0`. The README's table links each coordinate to its Maven Central artefact.

### Does the JVM target of the Firebase Kotlin SDK need extra setup?

Yes. It uses the GitLiveApp Firebase Java SDK for JVM, and the README states this requires additional initialization compared with the official Firebase SDKs. Firebase.initialize is the entry point, with behaviour depending on the platform and whether options are passed.

## Sources

- [GitLiveApp/firebase-kotlin-sdk on GitHub](https://github.com/GitLiveApp/firebase-kotlin-sdk)
- [License: Apache-2.0](https://github.com/GitLiveApp/firebase-kotlin-sdk/blob/master/LICENSE)
- [Project website](https://gitliveapp.github.io/firebase-kotlin-sdk/)
- [README](https://github.com/GitLiveApp/firebase-kotlin-sdk/blob/master/README.md)
- [Releases](https://github.com/GitLiveApp/firebase-kotlin-sdk/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/gitliveapp-firebase-kotlin-sdk