FlutterFire: Firebase plugins for Flutter apps

What FlutterFire is, and who ends up using it

FlutterFire is a monorepo of Flutter plugins, one per Firebase product, published under the firebase.google.com publisher on pub.dev. The README describes it as "a set of Flutter plugins that enable Flutter apps to use Firebase services". That sentence is the whole product: there is no server, no runtime and no hosted component. Each plugin is a Dart package that wraps the native Firebase SDK on Android and iOS, the Firebase JS SDK on web, and the corresponding SDK on macOS.

The audience is narrow. You are building a Flutter app, you have already decided to use Firebase for authentication, storage, messaging, analytics or a database, and you want to call those services from Dart rather than writing platform channels yourself. If any of those three conditions is false, FlutterFire is not the thing you are looking for.

Two projects that used to live here have moved out. Firebase UI now sits in its own repository, and the Cloud Firestore ODM moved to firebaseextended/firestoreodm-flutter. If you find an old tutorial pointing at a path inside this repo for either of those, the path is stale.

One plugin per product, with a shared core

The repository layout is a packages/ directory holding one folder per plugin: firebase_core, firebase_auth, cloud_firestore, cloud_functions, firebase_messaging, firebase_storage, firebase_analytics, firebase_app_check, and others. Each has its own pubspec.yaml, so you depend only on the products you use. There is also a platform interface layer, visible in the release history as firebase_core_platform_interface, which sits between the Dart API and the platform implementations. That split is why the Dart-facing API can stay the same while the Android, iOS and web implementations change underneath.

firebase_core is the one plugin every project needs. It initializes the Firebase app instance that the other plugins attach to. The README's plugin table lists per-platform support, and the table is the most useful page in the repository because it is honest about gaps. Analytics, App Check, Authentication, Cloud Firestore, Cloud Functions, Cloud Messaging and Cloud Storage all show a check mark for Android, iOS and web. macOS is marked with a beta symbol for the same products. Windows is the outlier: Authentication, Cloud Firestore and Cloud Storage carry an asterisk rather than a check, and Analytics, App Check, Cloud Functions and Cloud Messaging are marked N/A. Read that column before you promise a Windows build to anyone.

The plugins are versioned independently. The recent releases shown for this repository are all dev-tagged builds from July 2020 (firebase_core-v0.5.0-dev.1, firebase_core_web-v0.2.0-dev.1, firebase_core_platform_interface-v2.0.0-dev.1), which is a reminder that the package versions you put in your pubspec are not the repository version. You pin the plugin, not the monorepo.

Getting the plugins into a project

The README does not give install steps inline. It points to the Firebase documentation page "Add Firebase to your Flutter app" for setup, and to the Firebase for Flutter codelab for a worked example. It also links a page listing the available plugins. Those three links are where the project says to get it, and the repository itself contains no command to copy here.

What the README does tell you is which packages exist and what they are called. The plugin names in the table are the pub.dev package names: firebase_analytics, firebase_app_check, firebase_auth, cloud_firestore, cloud_functions, firebase_messaging, firebase_storage and firebase_core. Those names go into your pubspec.yaml dependencies, and each one has its own documentation link in the same table. The Core row's documentation link points at firebase.google.com rather than a product page, because firebase_core is the shared initialization layer rather than a product wrapper.

Because the plugins are versioned independently, the version you pin is a per-package decision. The repository's VERSIONS.md file exists to track which plugin versions belong together, which is the file to read when you upgrade several Firebase plugins at once.

Where FlutterFire stops helping you

The plugin table is the honest part of this project, and it should shape your plan. Windows support is the clearest limitation: Authentication, Cloud Firestore and Cloud Storage are marked with an asterisk, while Analytics, App Check, Cloud Functions and Cloud Messaging are marked N/A. A Flutter desktop build for Windows that depends on Cloud Messaging has no supported path through this repository.

macOS is marked beta across the products that support it. Beta in a plugin table means the API exists and the implementation ships, not that the behaviour is identical to mobile. Treat macOS as a platform you verify yourself rather than one you assume.

There is a second limitation that has nothing to do with platform coverage. FlutterFire is a client SDK collection. Anything that must not be trusted to the client, such as privileged writes or server-side validation, belongs in Cloud Functions or your own backend, with security rules enforcing it. Reaching for a plugin to do a job that needs server authority is the wrong use of this project, and the README does not present it as anything else.

Finally, the repository is a monorepo with independent package versions, so a fix in firebase_auth does not imply a fix in cloud_firestore. When you hit a bug, the relevant artifact is the individual pub.dev package and its changelog, not the repository as a whole.

FlutterFire against calling the platform SDKs directly

The real alternative is not another Flutter plugin collection. It is skipping the plugins and calling the native Firebase SDKs yourself through platform channels, or writing your own federated plugin. That approach gives you direct access to every SDK feature on the day it ships, including the ones the Flutter wrapper has not exposed yet, and it removes a layer from the call stack.

The difference in practice is maintenance surface. With FlutterFire you depend on packages published by firebase.google.com and upgrade them through pub. With your own channels you own the method channel definitions, the argument marshalling and the version pinning for each platform, and you own the bug when the native SDK changes. For a team shipping on Android and iOS only, with one or two Firebase products and a strong reason to be on the newest SDK feature, the hand-rolled route is defensible. For a team shipping on Android, iOS and web from one codebase, reimplementing three platform integrations is a large amount of work that FlutterFire already does.

The other alternative is not Firebase at all. If your backend is Supabase, Appwrite or your own API, FlutterFire solves nothing for you.

Maintenance, upgrades and the BSD-3-Clause licence

The repository is not archived, and the last push was on 2026-09-16. That is recent enough that the project is being worked on, and the VERSIONS.md file at the repository root exists specifically to track which plugin versions go together, which matters when you upgrade several Firebase plugins at once.

Upgrade cost is driven by the federated structure. Each plugin can release independently, so a routine pub upgrade can move firebase_auth and cloud_firestore by different amounts. The practical habit is to upgrade firebase_core first, since every other plugin depends on it, and to read the individual package changelogs rather than expecting one repository-level changelog to describe every change. The CHANGELOG.md at the repository root is the other file worth reading before an upgrade.

The licence is BSD-3-Clause, the same permissive family used across Google's Dart and Flutter packages. In plain terms it permits use and redistribution, including in closed-source applications, provided the copyright notice and licence text are retained. It does not grant trademark rights, and it comes with no warranty. That is a summary of the licence text, not legal advice; if your organisation has a policy on third-party licences, route the LICENSE file through it rather than relying on this paragraph. Note also that the plugins wrap Firebase SDKs and call Firebase services, which have their own terms separate from this repository's licence.

Editorial conclusion

Adopt FlutterFire when your Flutter app already uses Firebase and you want the plugins published under the firebase.google.com publisher on pub.dev instead of writing your own platform integration. Do not adopt it if your backend is not Firebase, or if you need Windows support for Authentication, Cloud Firestore or Cloud Storage, which the README marks with an asterisk rather than a check. Before committing, read the plugin table row for each product you plan to use and confirm the platform column for your target, then note that Firebase UI and the Cloud Firestore ODM now live in separate repositories, so any setup guide pointing into this repository for those two is stale.

Frequently asked questions

Official sources

1. firebase/flutterfire on GitHub
2. License: BSD-3-Clause
3. Project website
4. README
5. Releases