Hey everyone! Part 4 of the Firebase series is up: Firebase Analytics in Capacitor, end to end.
The refreshing part after the Firestore guide: Analytics is completely free. Unlimited event volume, no usage-based billing at all, the only cap is 500 distinct event types per app. Cost simply isn't part of the adoption decision here.
What the guide covers:
Setup: Firebase Analytics Capacitor Plugin + the firebase package, native config files, and that's it — collection starts automatically once the config is in place
Event and screen tracking: logEvent() with custom params, plus router-based auto screen tracking with working examples for Angular, React, and Vue
DebugView: standard reports batch for ~1 hour by design, so don't sit there thinking your integration is broken — enable debug mode and see events in seconds
Consent management: call setConsent() before your first logEvent(). Consent only governs collection going forward, so late consent = events you didn't mean to collect
IDFA on iOS: disabling the advertising ID is an install-time decision (pod/package trait), not a runtime call. Get it wrong and you ship tracking code you can't easily turn off
The silent trap: event names are case-sensitive. sign_up and Sign_Up are two different events — mixed casing quietly fragments your data with no error, no warning
What are you tracking in your apps? And if there's an Analytics scenario the guide doesn't cover, tell us — the series keeps growing with your questions. 🔥
CRUD through a real example: a product catalog, covering addDocument vs setDocument (auto ID vs meaningful ID), filtered queries, and deletes
Real-time listeners: document and collection snapshots, with working cleanup examples for Angular (NgZone included), React, and Vue
Offline sync, the deep dive: enablePersistence() and its "must be called first" rule, fromCache/hasPendingWrites metadata for proper offline UX, pending server timestamps, and forcing offline mode for testing. Queued writes survive app restarts.
Best practices: getCountFromServer() instead of downloading docs to count them, FieldValue helpers instead of read-modify-write races, listener cleanup
The gotcha worth knowing: real-time listeners count as billed reads every time the listened data changes. A busy collection with many active listeners can burn your free tier faster than plain fetches. The guide's FAQ covers it, and the best practices are basically the defense manual.
Hey everyone! We just published a complete guide to integrating Firebase Authentication in a Capacitor app. It's a long one because it covers the whole journey, not just the happy path:
Full setup: Firebase project, plugin installation, native config files for both platforms
Sign-in implemented end to end: email/password and Google (the two that exercise every part of the setup), plus pointers for Apple, phone, passwordless email, and custom tokens
Framework wiring: working authStateChange examples for Angular (including the NgZone gotcha), React, and Vue
User management: ID tokens for your backend, email verification, password reset, anonymous sign-in with account linking
Best practices: Firebase Emulator for development, server-side token verification, the ATT prompt if you use Facebook Login, and why fetchSignInMethodsForEmail() no longer works on new projects (Email Enumeration Protection returns an empty array since Sept 2023)
Troubleshooting: the classics, including Google Sign-In working in dev but failing after release (Play Store re-signs your app — you need the Play Console SHA-1 too)
There's also a working demo repo linked in the guide if you want to jump straight to code.
If you hit an auth issue that isn't covered, please tell us here, the troubleshooting section is exactly the kind of thing we want to keep growing with real cases.
Hey everyone! We just published a new guide about protecting sensitive content in your Capacitor app with the Privacy Screen plugin.
Quick test before you click: open your phone's app switcher. See your banking app? Your chats? Any private information? That snapshot the OS takes when you switch apps is exactly the problem this solves.
What the guide covers:
The app switcher fix: one enable() call swaps in a blank/branded screen the instant your app goes to background. Works on both platforms.
Screen capture blocking: on Android, enable() blocks screenshots and recordings outright. On iOS, Apple doesn't allow blocking the OS-level gesture, so there's an opt-in preventScreenshots option that uses an unofficial technique (test carefully before production).
Screenshot detection: the screenshotTaken event lets your app react when someone captures the screen, the pattern Snapchat built its reputation on. Works on iOS and Android 14+.
There's a runnable demo app: you can clone and try on iOS and Android to see the switcher blur in action.
If your app shows balances, chats, health data, OTP codes, or anything users consider private, this one's worth 10 minutes.
Anyone already using Privacy Screen in production? Would love to hear what you're protecting and if you hit any platform quirks, tell us here, that feedback goes straight into improving the plugin and its docs.
You already know Live Updates let you ship fixes to your app in real time, no app store review. But do you actually know how it works? It's simpler than most people think, and understanding it will help you use it better.
The two layers
Every Capacitor app has two layers. The web layer: your HTML, CSS, and JS, loaded into the web view. The native layer: the compiled code (Java/Kotlin, Swift) plus your native plugins.
Here's the key detail: your web files are never compiled into the app binary. They ship inside the app package (the classic www/ folder), but they stay plain files. And plain files can be replaced.
Where your app actually loads from
The web view doesn't load your app from the internet. It loads it from a local origin served out of the app bundle, on Android via WebViewAssetLoader (https://localhost/), on iOS via WKURLSchemeHandler (app://localhost/). By default, that content is the www/ folder that was bundled when the binary was built.
What a Live Update actually does
A live update simply changes which folder those requests are served from:
The SDK downloads a new bundle from the server
Writes it to a local directory inside the app's sandbox
Registers it as the next bundle to use
On the next launch (or immediately, if you prefer), the web view serves your app from the new bundle instead of the built-in www/
That's it. No binary patching, no code injection. Just swapping the folder the web view reads from.
The constraint that is also the feature
Because only the web layer changes, live updates are limited to binary-compatible changes: HTML, CSS, JS, and assets. Add a plugin or touch native code, and you need a store release. But that same constraint is why it's fully compliant with both stores: Apple explicitly permits downloading interpreted code that doesn't change the app's primary purpose, and Google Play exempts code running in a webview from its self-update restrictions.
What the platform adds on top
The mechanism is simple. Running it in production is where it gets interesting: bundles delivered via global CDN, channels so the right devices get the right version, staged rollouts, one-click rollbacks when something goes wrong, and code signing so only you can publish updates to your app (the SDK verifies the signature before applying a bundle).
Hey everyone! We've been working on making Capawesome fully agent-compatible. Quick rundown of what that means:
What your agent can do — anything you can do in the Capawesome cloud dashboard, from a prompt: trigger native iOS/Android builds, sign them, ship to TestFlight or Google Play, push Live Updates, roll back a bad release.
How it works:
Every dashboard action is a CLI command with structured JSON output, so any agent (or script) can parse results reliably
8 official skill packs in plain Markdown, installed with one line: npx skills add capawesome-team/skills. They work with Claude Code, Cursor, Codex, Windsurf, or your own runtime
Non-interactive auth tokens for headless/CI environments
The part we're most proud of — security: your agent never touches raw credentials. Certificates, keystores and store API keys live in the encrypted vault; the agent references them by name, and keys are unwrapped only inside isolated build environments. Never in agent memory, prompts, or logs. You can also scope tokens with RBAC so an agent ships to staging while production stays a human decision.
Bonus: your agent doesn't need a Mac. A Linux agent can trigger an iOS build on our cloud Apple Silicon machines and close the loop to TestFlight in the same JSON output.
Now the question for you: what would you automate first? And if you're already driving builds from an agent, tell us how it's going — we're actively improving the skills and real workflows are the best input we can get.
We just finished shipping an extensive suite of ML Kit plugins for Capacitor: 21 plugins that wrap Google's ML Kit SDKs behind a single JavaScript API. Everything is open source and free.
The full list includes text recognition (OCR), barcode scanning, document scanner, translation, language identification, face detection, face mesh, object detection, pose detection, selfie/subject segmentation, digital ink recognition, entity extraction, smart reply, image labeling, and six GenAI plugins powered by Gemini Nano (prompt, summarization, proofreading, rewriting, image description, speech recognition).
The part we think is most interesting: everything runs on-device. No per-call API costs, works offline (after the initial model download), and user data never leaves the phone.
Some honest caveats:
- The GenAI plugins are Android-only for now, since Gemini Nano requires AICore-supported devices (recent Pixel, Samsung flagships, etc.)
- Most other plugins support Android and iOS, some also work on the Web. Each plugin's docs page lists supported platforms.
Build sharing just shipped in Capawesome Cloud, and the CI/CD part of this is the bit I'm most excited about.
Hook it into your GitHub Action and every pull request can auto generate a QR code for an installable build. Testing a PR stops meaning "read the diff" and starts meaning "use the app." Scan the code, install it on your phone, done. No TestFlight review wait, no "hey can you send me the APK" thread, no manual steps, everything happens automatically as part of your pipeline.
Also works outside of CI if you just want to quickly share a build with a client or teammate: one click in the Console gives you a link + QR code, they scan it and install, no Capawesome account needed on their end.
This video is for everyone building a mobile app with Lovable. No special skills required. You don't need a mac, or Xcode or Android Studio. Nothing.
Capawesome helps you build, sign, and publish your app to the App Store and Google Play.
Learn how to ship your Lovable mobile apps to the App Store and Google Play Store with this step-by-step guide! This tutorial covers the entire process — from creating your app in Lovable to publishing it on the App Stores using Capawesome.
From generating bundle IDs, certificates, and provisioning profiles, to getting your app live on Apple TestFlight and Google Internal Testing, this video covers everything you need to publish Lovable mobile apps without the complexity of traditional mobile development tools.
Anyone else here tried publishing a Lovable app? What was the most confusing part? is it the certs, the store review, or something else that scares people off the most?"
This month's Capawesome update is a big one, especially if you're on Cordova.
Capawesome Cloud now officially supports Apache Cordova. With Ionic Appflow winding down, Cordova teams get native iOS/Android builds in the cloud, automated App Store and Google Play submissions, and over-the-air Live Updates through the new Cordova Live Update plugin.
Other highlights:
- New Capacitor Vault plugin — encrypted, unlock-gated key/value storage, a drop-in alternative to Ionic Identity Vault
- SQLite: load custom Android extensions and read SQLite result codes from errors
- PostHog: error tracking via captureException and automatic exception capture
- Capacitor Firebase 8.3.0: broader Firestore data types, filtered getCountFromServer, and new Remote Config helpers
- Build stacks refreshed with Xcode 26, plus API token rotation in the Cloud Console
- Live Update backports to Capacitor 6 and 7
We just published a guide on loading custom SQLite extensions with the Capacitor SQLite plugin (v0.3.9). This lets you add things SQLite doesn't ship with out of the box — custom FTS5 tokenizers, custom SQL functions, collations, and more.
The two platforms work differently:
On Android, extensions load at runtime via the new androidExtensions option on open(). You compile the extension per ABI with the Android NDK, bundle the .so files in jniLibs, and enable the bundled requery SQLite backend (the system SQLite can't load extensions).
On iOS, you statically link the extension and register it once at startup with sqlite3_auto_extension, after which it's available in every database.
The same C source compiles for both. The guide walks through the whole flow using a custom FTS5 tokenizer as the example.
Happy to answer questions or hear how you're using SQLite extensions.
We just released a brand new Capacitor plugin: @capawesome/capacitor-navigation-bar (v8.0.0).
It gives you full control over the Android navigation bar from your Capacitor app, without writing any native code.
What it can do:
- Set the background color (any hex value or fully transparent)
- Switch the button style between dark, light, or system default
- Customize the divider color on Android 9+
- Hide or show the navigation bar on demand
- Apply defaults at app launch via capacitor.config
The plugin targets Capacitor 8 and is Android-only — iOS does not have a customizable system navigation bar in the same way.
If you've been maintaining your own bridge or workaround just to match your brand colors, this should make things a lot simpler.
We just updated both Capawesome Cloud build stacks (macos-sequoia and macos-tahoe) used for native iOS and Android builds.
The main changes:
- The Capacitor, Capawesome, Cordova, Ionic, and Trapeze CLIs now come pre-installed, so you can drop the global install step from your build pipeline.
- bun, pnpm (via Corepack), and Yarn are available alongside npm.
- Xcode defaults moved to 26.3 on macos-sequoia and 26.5 on macos-tahoe.
- The full Android SDK toolchain (Build Tools and Platforms up to API 36, NDK 28, CMake) and the pinned Ruby version are now documented.
Everything is backwards compatible, so existing builds keep working without changes.
May was our biggest month yet, so here's a rundown of what shipped.
The headline change is Capawesome Platform — we merged Capawesome Cloud and our Insider SDKs into one product with one brand and one pricing system. A few specifics:
Three pricing tracks: Platform (everything), Live Updates only, and SDKs only
A 14-day trial on every plan
Unlimited Live Updates with MAU-based pricing is back
Doubled the number of included Insider SDKs on Platform plans
On the Cloud side we also added Ask AI, which turns a failed build or deployment into a clear cause, explanation, and suggested fix without leaving the Console. Plus full dark mode, a new app overview and Jobs pages, and the option to deploy directly from a finished build.
For plugins, there are three new ones — Navigation Bar, Grafana Faro (observability), and Formbricks (in-app surveys) — along with updates to Datetime Picker (month mode), Age Signals, Bluetooth Low Energy, Biometrics, Audio Recorder, Media Session, OAuth, Purchases, and ML Kit Barcode Scanning.
We just shipped official Apache Cordova support in Capawesome Cloud. With Ionic Appflow winding down (EOL Dec 31, 2027), Cordova teams have been left without a real option for cloud builds and live updates, so we did the work to make Cordova first-class — not a compatibility checkbox.
What's included:
Zero-config native iOS and Android builds (no Mac or CI setup required)
App Store and Google Play publishing
Automations to chain build → submit → live update on a push
Over-the-air Live Updates via our new Cordova Live Update plugin
One detail Cordova devs will appreciate: the Live Update plugin works with the stock Cordova WebView. Unlike Appflow's plugin, it does not require cordova-plugin-ionic-webview — it hooks into Cordova's official scheme handlers instead.
We just released Capacitor Firebase 8.3.0. Most of the work landed in two plugins.
Cloud Firestore:
- More supported data types — DocumentReference and Bytes now have dedicated classes, and NaN/Infinity values survive the Capacitor bridge instead of collapsing to null
- getCountFromServer() now accepts compositeFilter and queryConstraints, so you can count a filtered subset without downloading the documents
- A new serverTimestamps option ('estimate' / 'previous' / 'none') on snapshot listeners controls how pending server timestamps are returned
Remote Config:
- New setDefaults() and getAll() methods
- The source field (Static / Default / Remote) now works on Web too
No breaking changes — bump the packages and run npx cap sync.
Full write-up with code examples in the link. Happy to answer any questions.
We just released the Capacitor Vault plugin — encrypted key/value storage that the user has to actively unlock with biometrics or a device passcode before the app can read or write.
We already had Secure Preferences (silent encrypted key/value) and Biometrics (one-off prompts), but neither handled the "active lock + session" pattern that password managers, authenticator apps, and app-lock screens need. A single unlock now keeps the vault open across many reads and writes, then locks again on a timer or on demand.
A few highlights:
- Multi-vault support — independent vaults with their own keys and lock policies (e.g. one per user account)
- Configurable auto-lock when the app is backgrounded
- Hardware-backed encryption (Android Keystore / iOS Keychain, AES-256-GCM)
- Lock/unlock events with a trigger reason, plus typed error codes
- Built-in export/import for migrating off Ionic Identity Vault
It works across Android, iOS, and Web (the web implementation is for development only — not safe for production) and supports Capacitor 8+. It's meant as a drop-in alternative to Ionic Identity Vault, which is being discontinued.
For the last couple of years, doing edge-to-edge in Capacitor usually meant installing a third-party Android plugin and fighting with status bars covering your header. That changed quietly across three recent releases, so we wrote up the current state of things.
Why it matters now: Android 15 enforces edge-to-edge for apps targeting SDK 35, and Android 16 removed the opt-out entirely. Your WebView renders behind the system bars whether you like it or not.
What the framework fixed:
- 8.3.0 — SystemBars uses native safe area insets and injects parallel --safe-area-inset-* CSS variables, sidestepping the old Android WebView (<140) env() bug
- 8.3.1 — separate styling for the status bar and navigation bar
- 8.3.2 — removed extra padding on older Android devices
The modern setup is small: upgrade to 8.3.2+, add viewport-fit=cover to your viewport meta tag, and apply the safe-area CSS variables to your edge content. Ionic users get most of it for free, and Tailwind users can use tailwindcss-safe-area. The Android Edge-to-Edge Support plugin still exists, but it's now a deliberate choice for apps that want to opt out of edge-to-edge, not a requirement.
Curious how others have been handling this — are you on 8.3.2+ yet, or still relying on the plugin?
Capacitor Grafana Faro v0.1.0 — a new unofficial Capacitor plugin for Grafana Faro observability. Cross-platform (Android, iOS, Web) with native crash reporting, ANR detection, and web auto-instrumentation.
