Capacitor Firebase: native Firebase behind one Capacitor API

A collection of plugins, versioned as one

Capacitor Firebase is a collection of Capacitor plugins that make it easier to use Firebase in a Capacitor project, and the repository description says it plainly: Firebase plugins for Capacitor, supporting Android, iOS and the Web.

The structure is a set of separate packages rather than one plugin. The README's plugin table lists Analytics, App, App Check, Authentication, Crashlytics, Cloud Firestore, Cloud Functions, Cloud Messaging, Cloud Storage, and the release history shows Performance and Remote Config published at the same time. Each has its own package under the @capacitor-firebase scope, and each has its own installation instructions, which the README is explicit about: each plugin has its own installation instructions, and you click the name of the desired plugin in the Plugins section to reach the guide.

The design decision that matters is the consistent versioning, which the README lists as no more SDK versions conflicts. Because the packages are published from a monorepo in a single release run, they share a version number, and the recent release tags demonstrate it: @capacitor-firebase/[email protected], @capacitor-firebase/[email protected] and @capacitor-firebase/[email protected] were all published on 2026-09-17, seconds apart.

That matters because the failure this project addresses is specific. A Capacitor application is three codebases, a web bundle, an Android app and an iOS app, and the native Firebase SDKs are versioned on Google's schedule while the JavaScript SDK is versioned on npm's. When a plugin wraps a native SDK, the plugin version becomes the ceiling on the native SDK version, and mismatched plugin versions pull in mismatched native SDKs. Locking the plugin versions together removes one dimension of that problem.

The remaining features are the ones a shared wrapper should provide: support for Android, iOS and the Web, Capacitor 8 support, support for the modular Firebase Web SDK, unified TypeScript definitions, and full documentation. The README also says the project is under active development with more plugins to come, and the repository is part of the Capawesome collection and of Google's DevLibrary.

What the plugins cover, and who maintains them

The plugin list is the product, so it is worth reading as a map of what a Firebase application actually needs.

The set spans the whole platform. App is the base package that other plugins depend on. Authentication covers sign-in. App Check is the attestation layer that lets a backend trust the app binary. Cloud Firestore is the document database, Cloud Storage the file store, Cloud Functions the callable backend, Cloud Messaging the push notifications. Analytics is usage telemetry, Crashlytics is crash reporting, Performance is the tracing and metrics product, and Remote Config is the server side feature flagging.

That coverage is a reasonable definition of a Firebase application, and the set of questions in the FAQ-style pages per plugin follows the same shape, because each plugin's guide covers configuration, the platform specific setup such as the Android google-services.json file or the iOS capabilities, and the API surface.

The maintenance is narrow and named. The README's maintainers table lists one person, Robin Genz, with the GitHub handle robingenz and a social account, and the project is a Capawesome project, which is a collection rather than a company. That has a practical reading for an adopter: this is one maintainer's collection of wrappers, and the risk profile is different from Google's own SDKs even though the underlying native libraries are Google's.

The primary language in the repository is Java, which is a reminder of what these plugins are. They are native Android and iOS implementations with a TypeScript bridge, not JavaScript re-implementations of Firebase. That distinction decides the trade-off, and it is the subject of the next section.

Native SDKs behind a bridge, not a JavaScript SDK in a web view

The most important thing to understand about this project is what it is not. It is not a JavaScript implementation of Firebase that runs everywhere.

A Capacitor application is a web application running inside a native shell, and the default way to use Firebase in that setup is the Firebase JavaScript SDK, which runs entirely in the web layer. That works, and it is simple, but it is not the same product. The JavaScript SDK talks to Firebase over its HTTP and streaming interfaces, while the native SDKs on Android and iOS use Google's own client libraries, and those are the ones with features the web SDK does not expose in the same form.

This project takes the native route and puts a bridge in front of it. The feature list names the modular Firebase Web SDK support, which is the one place the web implementation appears, and the unified TypeScript definitions are what the caller sees regardless of platform. The point of the collection is that your code calls one API and the plugin resolves to the native implementation on Android and iOS, or to the web SDK on the web target.

The topics on the repository make the split concrete, with capacitor-android, capacitor-ios, capacitor-plugin, capacitor-community, and separate entries for firebase-analytics, firebase-app-check, firebase-auth, firebase-crashlytics, firebase-database, firebase-messaging, firebase-performance, firebase-remote-config and firebase-storage, alongside android, ios and web.

So the choice you are making is not plugin versus no plugin, it is native SDK versus web SDK, with the plugin making the native choice available without writing the bridge yourself three times.

The verify pipeline: three platforms, one turbo command

The package.json in the repository root describes the development and release machinery, and it is the clearest picture of how a monorepo of native plugins is kept consistent.

It is an npm workspaces monorepo, with the workspaces set to packages/*, the package manager pinned to [email protected], and Turbo doing the orchestration. The verification entry point is a single script that fans out to all three platforms:

npm run verify
npm run verify:android
npm run verify:ios
npm run verify:web

Underneath, each of those runs Turbo with a deliberately conservative set of flags, for example:

turbo run verify:android --concurrency=1 --no-cache --env-mode=loose

The concurrency of 1 and the disabled cache are the interesting part, and they are there for a reason. A native plugin verification needs a real Android toolchain, a real iOS toolchain and a browser, and running them at once on a developer machine produces failures that have nothing to do with the code. Serialising the tasks and refusing to reuse cached results turns an unreliable local check into a slow but trustworthy one, which is the right trade for a plugin set that ships to native app stores.

The script set is longer than that, and the shape is the interesting part. There is a parallel set of affected commands, affected:verify, affected:lint, affected:fmt, affected:docgen, affected:build and the two iOS dependency installers, and the affected variants add Turbo's --affected flag so that a change in one package only checks that package and its dependents. There are the standard ones, lint, fmt, docgen and build, and the iOS dependency installers for CocoaPods and Swift Package Manager, ios:pod:install and ios:spm:install, both also with affected variants. There is a docgen task, which is how the per plugin API documentation stays generated rather than written by hand.

The release path uses Changesets, with the release script running a build and then changeset publish, and a release:preview script that publishes to pkg-pr-new so a pull request can be installed as a real package before it is merged.

Patches, hooks, Swift linting and the rest of the tree

A few other things in the tree tell you what kind of project this is.

The postinstall script runs patch-package, and there is a patches directory at the root, which means the project ships modifications applied to its dependencies at install time. That is a technique that solves real problems in a monorepo with native dependencies, and it is also the kind of thing that breaks silently when an upstream package changes shape, so it is worth knowing about before an upgrade surprises you.

The prepare script runs husky, and there is a .husky directory, so the git hooks are installed for anyone who clones the repository. The formatting side is Prettier, with a .prettierrc.js, and the iOS code is linted with SwiftLint through swiftlint.config.js, which makes sense for a repository that carries Swift sources alongside Java and TypeScript.

There is a .changeset directory, which is the working area for the Changesets release notes, and a turbo.json holding the Turbo pipeline configuration. The .github directory carries the CI workflow, whose badge in the README points at ci.yml on the main branch, and there is a maintenance badge that reads yes for 2026, so the project is publishing against a current year rather than a stale one.

The documentation lives in a docs directory, and there is a CITATION.cff file, which is a small sign of maturity: it lets the project be cited with a DOI-like identifier, which matters if you are writing an academic or internal report that uses these plugins.

Two more entries are worth a glance because they are unusual for a plugin repository. There is a .claude directory and an .agents directory, which suggests the project carries its own agent instructions and tooling configuration, and a skills-lock.json, which suggests the maintainers consume some skill-based tooling of their own. Neither affects a consumer of the packages, but both say something about how the work is done.

Licence, cadence and the shape of the risk

The licence is Apache-2.0, with the LICENSE file at the root of the repository, which is the permissive licence with an explicit patent grant and is the same licence the native Firebase SDKs ship under, so there is no licensing friction in combining them.

The cadence is regular. The recent releases are all 8.5.2 across the packages, published on 2026-09-17, and the last push to the repository was on 2026-10-21. The version number tracks Capacitor's major version, since the README lists Capacitor 8 support, which tells you the whole collection is upgraded as a block when Capacitor moves.

The risk to weigh is concentration, not staleness. The native SDKs underneath are Google's, and they have their own release cadence, and the plugin has to release a new version when the native SDK underneath moves in a way that requires it. If you adopt several of these plugins, you are adopting several coupled dependencies on Google's release schedule, mediated by one maintainer.

There is a SECURITY.md at the root, which is the file to point a security researcher at, and a CONTRIBUTING.md. The repository is also listed as part of Google's DevLibrary, which is a listing rather than a support commitment, but it does mean the collection is indexed alongside the other maintained integrations for these SDKs.

The honest summary is that this is a well-organised, actively maintained community wrapper set that removes the version alignment problem that a mixed platform Capacitor app would otherwise have, at the cost of depending on a single maintainer to track the native SDKs for you. If your app needs the native SDKs rather than the web SDK, that trade is usually worth it, and the per plugin installation guides are where the real work is.

Editorial conclusion

Adopt Capacitor Firebase if you are building a Capacitor application that needs Firebase on device, and you want the native Android and iOS SDKs behind one TypeScript API rather than a web-only SDK running inside a web view. Do not adopt it if your application is web only, where the Firebase JavaScript SDK is simpler and has no bridge in the middle. Verify first which plugins you actually need, because each one is a separate package with its own install instructions and its own native dependency, that Capacitor 8 is the version you are on, since that is what the README lists as supported, and that the native SDK versions each plugin pulls in are compatible with the versions your app already ships, because a native dependency conflict is the failure mode this project exists to reduce rather than to remove.

Frequently asked questions

Official sources

1. capawesome-team/capacitor-firebase on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases