--- title: "How to Use Firebase in a Capacitor App" description: Use Firebase in a Capacitor app with the native plugin family — Authentication, Firestore, Storage, Analytics, Messaging, Crashlytics, and more. date: created: 2026-09-13 updated: 2026-09-13 authors: - djabif categories: - Capacitor - Firebase - Guides - SDKs links: - Capacitor Firebase Plugins: sdks/capacitor/firebase/index.md faq: true --- # How to Use Firebase in a Capacitor App Firebase is a suite, and most real apps end up using several parts of it: sign-in, a database, file storage, analytics, push notifications, crash reporting. In a Capacitor app you reach all of them through the [Capacitor Firebase plugins](../../sdks/capacitor/firebase/index.md), a family that wraps the native Android and iOS Firebase SDKs (and the Firebase JS SDK on web) behind one consistent TypeScript API. This post covers which plugin does what, the setup they all share, how the pieces fit together in a real app, and links to a dedicated guide for each one so you can go as deep as you need.
Build and deploy your Capacitor app with Capawesome Cloud
## Key Takeaways - The Capacitor Firebase plugins wrap the native Firebase SDKs, so you avoid running the Firebase JS SDK inside a WebView on native platforms. - Each Firebase service is a separate plugin you install only if you need it: Authentication, Firestore, Storage, Analytics, Messaging, Crashlytics, App Check, Cloud Functions, Remote Config, and Performance Monitoring. - They share one setup: a Firebase project, the `google-services.json` / `GoogleService-Info.plist` config files, and `npx cap sync`. - The plugins are designed to work together. Authentication supplies the user ID that Firestore rules, Crashlytics, and Cloud Functions all rely on. - Crashlytics is Android/iOS only; the rest also run on the web. ## The Firebase Plugins for Capacitor at a Glance Each Firebase service is its own plugin. Here's the whole family and what each one is for, with a dedicated guide for the common ones: | Plugin | What it does | Guide | | --- | --- | --- | | **Authentication** | Sign users in with email, phone, and social providers | [Firebase Authentication in Capacitor](./capacitor-firebase-authentication-guide.md) | | **Cloud Firestore** | Store and sync structured data in real time, with offline support | [Capacitor Firestore: Real-Time Data & Offline Sync](./capacitor-firebase-cloud-firestore-guide.md) | | **Cloud Storage** | Upload and download user files (images, documents) | [Upload & Manage Files with Firebase Storage in Capacitor](./capacitor-firebase-cloud-storage-guide.md) | | **Analytics** | Track events, screens, and conversions | [Track App Events with Firebase Analytics in Capacitor](./capacitor-firebase-analytics-guide.md) | | **Cloud Messaging** | Send push notifications | [Capacitor Push Notifications: The Complete Guide](./capacitor-push-notifications-guide.md) | | **Crashlytics** | Crash and non-fatal error reporting (Android/iOS) | [Crash Reporting in a Capacitor App with Crashlytics](./capacitor-firebase-crashlytics-guide.md) | | **App Check** | Attest that requests come from your genuine app | [Firebase App Check in a Capacitor App](./capacitor-firebase-app-check-guide.md) | | **Cloud Functions** | Call serverless backend logic | [Call Firebase Cloud Functions from a Capacitor App](./capacitor-firebase-cloud-functions-guide.md) | | **Remote Config** | Feature flags and remote values | [Feature Flags in a Capacitor App with Remote Config](./capacitor-firebase-remote-config-guide.md) | | **Performance Monitoring** | Measure app-start, rendering, and custom traces | [Monitor App Performance in Capacitor with Firebase](./capacitor-firebase-performance-monitoring-guide.md) | There's also a core App plugin that initializes Firebase and exposes app-level info; you rarely use it directly, since each service plugin handles its own initialization. ## Why Native Plugins Instead of the Firebase JS SDK? You *can* run the Firebase JavaScript SDK inside your Capacitor WebView on every platform. The reasons not to are consistent across the suite: every call crosses the WebView-to-native bridge instead of talking to the platform SDK directly, offline caching falls back to the WebView's storage instead of the native on-device cache, and (most acutely for Authentication) social sign-in inside an embedded WebView is something the providers actively restrict. The native plugins use each platform's own Firebase SDK, and fall back to the JS SDK only on the web, where there's no native alternative. ## When Is Firebase a Good Fit for a Capacitor App? Firebase is a strong default when you need a backend but don't want to run one. It's a good fit for: - **Apps that need common backend pieces fast** (auth, a real-time database, file storage, and push) without standing up servers. MVPs, consumer apps, social and chat apps, marketplaces, and event apps all map cleanly onto it. - **Small teams** that would rather ship features than operate infrastructure. The managed services scale on their own, and the free tier is generous enough to launch on. - **Cross-platform apps**, since the same TypeScript API works across Android, iOS, and the web. You're not maintaining three separate integrations. What it makes easier, concretely: one project gives you a single user identity that Firestore rules, Cloud Functions, and Crashlytics all share; you get real-time sync and offline support without writing either; and push, analytics, crash reporting, and remote config are a plugin install apart rather than a separate vendor each. It's a weaker fit when: - **Your data is highly relational.** Firestore is a NoSQL document store: joins, complex reporting queries, and rigid schemas fight against it. A relational database behind your own API may serve you better. - **You need control over the backend or where data lives.** On-prem requirements, strict data-residency rules, or a need to own the whole stack point away from a managed service. - **You're read-heavy at large scale.** Real-time listeners bill per read, so a very busy app with many active listeners can get expensive. Model your reads before you commit. - **You already have a backend.** If your API is built, you might adopt only the pieces that stand alone (Authentication, Cloud Messaging, Crashlytics) rather than moving your data into Firestore. If you're coming from an existing Angular web app, the fastest path to a Firebase-backed mobile app is to wrap what you already have. See [How to Wrap an Angular App with Capacitor and Firebase](./how-to-wrap-an-angular-app-with-capacitor-and-firebase.md) for a full walkthrough. ## The Setup Every Firebase Plugin Shares Whichever plugins you pick, the foundation is the same three things. 1. **Create a Firebase project** in the [Firebase console](https://console.firebase.google.com/){:target="_blank"} and register an app for each platform you target (Android, iOS, Web). 2. **Add the config files** Firebase generates: `google-services.json` into `android/app/`, and `GoogleService-Info.plist` into `ios/App/App/` (added to the Xcode project, all targets). Full steps are in the plugin's [Add Firebase to your project](https://github.com/capawesome-team/capacitor-firebase/blob/main/docs/firebase-setup.md){:target="_blank"} guide. 3. **Install each plugin you need and sync.** For example: ```bash npm install @capacitor-firebase/authentication @capacitor-firebase/firestore npx cap sync ``` From there, each plugin has its own specifics: a Gradle plugin for Crashlytics and Performance, provider setup for Authentication and App Check, a Storage bucket, and so on. Its guide in the table above walks through them. ## How the Plugins Fit Together in a Real App The plugins are most useful in combination. Picture a marketplace app: - **Authentication** signs the user in. That sign-in produces a Firebase user ID that everything else keys off. - **Cloud Firestore** stores listings, orders, and profiles, with security rules that check `request.auth`, populated automatically because the user signed in natively. - **Cloud Storage** holds the listing photos; you save each file's path in Firestore alongside the structured data. - **Cloud Functions** runs the checkout (the trust-sensitive logic you keep off the client) and receives the user's auth token automatically on every callable request. - **App Check** makes sure those Firestore and Functions calls come from your real app, not a script. - **Cloud Messaging** notifies a seller when their item sells. - **Analytics** tells you which screens convert, and **Remote Config** lets you flip a new checkout flow on for 10% of users. - **Crashlytics** and **Performance Monitoring** watch stability and speed in production, tied back to the same user ID. None of these require the others, but they're designed to share one identity and one project, rather than leaving you to stitch together separate services. ## Which Firebase Plugins Do You Actually Need? Start with the problem, not the suite. A rough guide: - **Users and data:** Authentication + Cloud Firestore (or Cloud Storage for files) cover the majority of apps. - **Growth and insight:** Analytics, plus Remote Config for staged rollouts. - **Reliability:** Crashlytics and Performance Monitoring, usually added together. - **Backend and security:** Cloud Functions for server logic, App Check to protect it. - **Engagement:** Cloud Messaging for push. Install only what you use. Each plugin is independent, so there's no penalty for adopting them one at a time as the app grows. ## Best Practices Across the Firebase Plugins A few habits pay off no matter which plugins you use: - **Install only what you need.** Each plugin is independent. Adopt them one at a time as features land, rather than pulling in the whole suite up front. - **Use one Firebase project per environment.** Separate dev, staging, and production projects so test data and test crashes never mix with real ones. - **Secure data with rules *and* App Check.** Security Rules decide *who* can touch data; [App Check](./capacitor-firebase-app-check-guide.md) decides *what app* can. Real protection uses both. - **Lean on the shared identity.** The [Authentication](./capacitor-firebase-authentication-guide.md) user ID ties Firestore rules, Cloud Functions, and Crashlytics reports to the same user. Set it everywhere it's accepted. - **Keep secrets off the client.** Anything a user shouldn't see (API keys, privileged logic) belongs in a [Cloud Function](./capacitor-firebase-cloud-functions-guide.md), never in a Remote Config value or client code. - **Mind the free-tier edges.** Firestore reads, Storage bandwidth, and phone-auth SMS are billed on usage; Analytics, Crashlytics, and Performance Monitoring aren't. Know which is which before you scale. ## Common Gotchas Across the Firebase Plugins The same handful of surprises come up again and again: - **Missing config files crash the app on launch.** A misplaced `google-services.json` or `GoogleService-Info.plist` (or one not added to the Xcode project) is the single most common setup failure across every plugin. - **Native sign-in doesn't authenticate the web layer.** Signing in through the Authentication plugin authenticates the native SDKs, not the Firebase JS SDK, which matters if you mix native sign-in with web-only Firebase calls. - **Crashlytics only sees native crashes.** It's Android/iOS only, and your JavaScript errors won't appear unless you report them yourself with `recordException(...)`. - **Data shows up on a delay.** Analytics batches for about an hour and Performance Monitoring for up to ~12 hours. An empty dashboard right after a test usually means "wait," not "broken." - **Remote Config caches aggressively.** The default fetch interval is about 12 hours, so config changes look stuck in development until you lower it. - **iOS needs extra steps per plugin.** Readable Crashlytics reports need dSYM upload, and each plugin needs the SPM `symlink` package option to avoid a package-identity collision. ## FAQ ### Does Firebase work with Capacitor? Yes. The Capacitor Firebase plugins wrap the native Android and iOS Firebase SDKs (and the JS SDK on web), so you can use Firebase Authentication, Firestore, Storage, Analytics, Cloud Messaging, Crashlytics, and more in a Capacitor app across all three platforms. ### Does Firebase work with Ionic apps? Yes. Ionic apps run on Capacitor, so the same plugins and setup apply with nothing Ionic-specific to do. You call the plugins from your Ionic pages or components like any other service. ### Do I have to install every Firebase plugin? No. Each Firebase service is a separate plugin, so install only the ones you need (for example Authentication and Firestore) and add others later. They share the same Firebase project and config files. ### Which Firebase features work on the web with Capacitor? Most do: Authentication, Firestore, Storage, Analytics, Cloud Messaging, App Check, Cloud Functions, Remote Config, and Performance all have a web implementation via the Firebase JS SDK. The main exception is Crashlytics, which is Android and iOS only. ### Is Firebase free to use in a Capacitor app? The plugins are free and open source, and Firebase itself has a free tier. Some services (Firestore, Storage, Cloud Functions, phone auth) bill on usage beyond that tier, while others (Analytics, Crashlytics, Performance Monitoring) have no usage-based cost. Check the current [Firebase pricing page](https://firebase.google.com/pricing){:target="_blank"} before scaling. ## Where Capawesome Cloud Fits in a Firebase App Firebase covers the backend: identity, data, files, messaging, analytics. What it doesn't do is build, sign, ship, and update your actual app. That's the half [Capawesome Cloud](https://capawesome.io/){:target="_blank"} handles, and the two line up cleanly: - **Native builds and signing.** Firebase's native features depend on a correctly signed app. App Check's Play Integrity is tied to your Play signing key, and Apple sign-in and App Attest to your bundle ID and Apple team. Capawesome Cloud builds and signs your iOS and Android apps in the cloud, so that signing identity stays consistent across every release without a local Xcode and keystore setup to maintain. - **Live updates for the web layer.** Most of what you tune in a Firebase app lives in your web bundle: sign-in flows, Firestore queries, analytics events, how you read a feature flag. Live updates ship those changes over the air, so a fix reaches users the same day instead of waiting on an app store review. - **App store publishing.** When you do need a native release, Cloud automates the TestFlight and Play Store submission. Two pairings are especially natural in a Firebase app: - **Remote Config plus live updates** give you a true dark launch. You ship new code with a live update while it stays hidden behind a flag, then enable it for a slice of users from the Firebase console, with no deployment in between (see [Feature Flags in a Capacitor App with Remote Config](./capacitor-firebase-remote-config-guide.md)). - **Crashlytics or Performance Monitoring plus live updates** close the loop. A crash or slow-trace report points at a web-layer bug, and a live update ships the fix the same day you spot it. [Try Capawesome Cloud Free](https://capawesome.io){ .md-button .md-button--primary } ## Conclusion If you're starting from zero, install Authentication first, then add each other plugin when a feature calls for it. The user ID that sign-in produces is what Firestore rules, Cloud Functions, and Crashlytics reports key off, so getting it in place early saves rework later. Then pick the guide for the piece you're adding next: - [Firebase Authentication in Capacitor: Setup & Best Practices](./capacitor-firebase-authentication-guide.md) (usually the first piece, since so much else keys off the user) - [Capacitor Firestore: Real-Time Data & Offline Sync](./capacitor-firebase-cloud-firestore-guide.md) (the database most apps reach for next) - [Crash Reporting in a Capacitor App with Crashlytics](./capacitor-firebase-crashlytics-guide.md) (the fastest way to find out what's breaking in production) - [How to Wrap an Angular App with Capacitor and Firebase](./how-to-wrap-an-angular-app-with-capacitor-and-firebase.md) (a full walkthrough if you're starting from an existing Angular web app) For questions along the way, join the [Capawesome Discord server](https://discord.gg/VCXxSVjefW){:target="_blank"}. The [Capawesome newsletter](https://capawesome.io/newsletter/){:target="_blank"} will bring you the rest of this series as it publishes.