FCM-toolbox gives push notifications a public test bench

A shared public instance, and the warning attached to it

The project exists for one job: making Firebase Cloud Messaging testable without setting up a whole Firebase project first. The README describes it as a public toolbox that lets you test and debug the FCM service, and lists three capabilities: send and receive FCM messages, manage registered devices, and self hosting.

The third capability is where the real design decision sits, because the first two come with a condition. The README states that on the public toolbox versions, users share the same FCM and FRD instances, followed by the instruction to be responsible. FRD here is the Firebase Realtime Database, and the public web app is hosted at fcm-toolbox-public.web.app. So the hosted version is a shared workbench: you send a message, someone else's registered device may also receive it, and the device list is shared with everyone else using it.

That makes the public instance good for exactly one thing, which is checking that a payload reaches a device at all, and bad for anything involving real user data, real tokens or a quiet environment. The project also carries a `privacy_policy.md` at the repository root, which is the file to read before you point anything real at the shared instance.

The Android app announces itself and keeps every message

The Android side is where the test actually lands, since the point of FCM is delivery to a device. The app is published on the Play Store under the package identifier `fr.smarquis.fcm`, and release versions are also available from the project's GitHub releases, so you can install a build rather than compile one.

Three behaviours are listed for the app. It notifies its presence and sends its FCM token to a remote server, which is how a device enters the registry the web console can then target. It issues a notification for each message received, so a test payload produces a visible system notification. And it retains all received messages, which turns the phone into a log of everything that was pushed to it rather than only a transient alert.

The retention is the feature that makes the tool useful for debugging and the reason not to point it at production traffic. A developer checking a specific payload can read the message back rather than trust a screenshot, and the list screen shows the history in one place. The images in the repository, `android_empty.png`, `android_list.png` and `android_notifications.png`, correspond to the empty state, the message list and the notification shade, which tells you the app was designed around reviewing messages rather than around a single successful delivery.

The web app is the sending side and the device registry

The web application is the other half. It lives at fcm-toolbox-public.web.app and does three things according to the README: it sends multiple types of payloads, it maintains a local list of devices, and it shows which devices are online.

Sending multiple types of payloads matters because FCM messages come in several shapes, and the failure you are chasing is often a malformed one rather than a broken delivery. The app also keeps a local list of devices, which is the piece that makes targeting possible from a browser without writing a request against the FCM HTTP API by hand, and the online view tells you whether the device you are about to target is actually connected.

The configuration section is short and points to the official Firebase documentation for the JavaScript client. The README says you can host your own version of the web FCM toolbox, or simply provide your own Firebase identifiers. The two options are different in kind. Hosting your own copy gives you a deployment you control, while supplying your own identifiers is closer to a configuration change and keeps the hosted app serving the code.

The screenshots referenced in the README, `web.png` and `web_configuration.png`, show the console and the configuration screen, so the web app is the place where identifiers are entered and the device list is managed.

Self hosting means bringing your own Firebase project

Both halves of the toolbox can be pointed at a Firebase project you own, and this is where the separation from the public instance becomes real.

For the Android app, the README says you can build your own version and provide your own `google-services.json` file, with a link to the official documentation for the Android client. The `google-services.json` file is the standard Firebase configuration file that the Android SDK reads, so swapping it is what moves the app from the shared backend to your own project. The trade is that you now maintain a build, and the Play Store build is no longer the thing under test.

For the web app, the equivalent step is providing your own Firebase identifiers or hosting the app yourself. Between the two, the web app is the cheaper half of the self hosting story, since it is a static deployment and the identifiers are configuration, while the Android app needs the toolchain in the repository, which includes a Gradle wrapper, `build.gradle.kts`, `settings.gradle.kts`, `gradle.properties` and a `gradle/` directory.

The repository also has a `firebase/` directory and a `docs/` directory, and the `.run/` directory at the top level holds IDE run configurations. The `firebase/` directory is consistent with a project that expects its hosting and configuration to live with the source, which is the arrangement that makes a self hosted copy a deployment rather than a patch.

What the project does not do is give you a production monitoring story. It is a test bench, and the README describes nothing about delivery receipts, metrics or message retention policies for a deployment of your own.

A Kotlin and Gradle repository with a web app alongside

The repository layout describes two deliverables in one tree. The top level holds the Gradle project files, `build.gradle.kts`, `settings.gradle.kts`, `gradle.properties`, the `gradle/` directory and the `gradlew` and `gradlew.bat` wrapper scripts, so a build is a `./gradlew` invocation rather than a locally installed Gradle. There is also `gradle/` with the wrapper distribution configuration, which is the usual way to pin a build tool version across a team.

The `app/` directory is the Android application module, and the Kotlin primary language of the repository is what that module is written in. Alongside it, `firebase/` holds the web side, `docs/` holds documentation, `art/` holds the images used in the README, and `privacy_policy.md` states the terms for the published apps.

The `.run/` directory is worth a second look for anyone planning to work on this. Shared IDE run configurations mean the project ships with a known way to launch each part, which removes the guesswork when you are trying to run the Android app and the web app together against the same Firebase project.

The project is Apache-2.0 licensed with the `LICENSE` file at the root, so the code can be reused and modified in a product without a copyleft obligation, as long as the notices travel with it.

The last release is older than the last commit

The release history is short and dated. Version 1.10.1 came out on 2024-11-01, 1.11.0 on 2025-06-26 and 1.11.1 on 2025-08-09, with the tags named after the version numbers rather than anything else.

The last push to the repository was on 2026-10-19 and the project is not archived, so work has continued since the 1.11.1 tag. The gap between a repository that is still receiving commits and a latest release from 2025-08 is the practical fact to plan around. It means the code on the default branch is ahead of what the Play Store build and the release archives contain, and it means a bug you report may already be fixed on master and not yet shipped.

For a testing tool, that is a moderate risk rather than a serious one. The dependency that matters is the Firebase SDK inside the app, and that moves independently of this repository. What a user should decide is which artefact to trust: the published Play Store app for a quick check, a release build for a repeatable test, or a build from the current branch when you need a fix that has not shipped.

The self hosting path pushes that decision further. Anyone running their own copy of the web toolbox with their own Firebase identifiers is already building from source, and at that point the release cadence matters less than the state of the default branch.

Editorial conclusion

FCM-toolbox suits a mobile developer who needs to see a push message arrive on a real device, and it does not suit a team that needs an isolated environment on the public instance, because every user of it shares the same Firebase project and realtime database. Before you rely on the hosted version, read the warning in the README about shared instances, and decide between the public instance and a self hosted copy with your own Firebase identifiers before you start sending test payloads.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. SimonMarquis/FCM-toolbox on GitHub