u/DayanaJabif

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

📖 https://capawesome.io/blog/capacitor-firebase-analytics-guide/

Previous parts: Authentication · Firestore · Cloud Storage

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. 🔥

Hey everyone! Part 2 of the Firebase series is up: the complete guide to Cloud Firestore in Capacitor. 🔥

What it covers:

• Setup: database creation, security rules, Firestore plugin installation, native config
• 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.

📖 https://capawesome.io/blog/capacitor-firebase-cloud-firestore-guide/

Yesterday's Authentication guide pairs with this one (your security rules need request.auth, which native sign-in populates automatically):

Anything Firestore-related you'd want covered that isn't here? The series continues and your questions literally shape what we write next. 🙌🏽

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)

📖 https://capawesome.io/blog/capacitor-firebase-authentication-guide/

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.

📖 Guide: https://capawesome.io/blog/capacitor-privacy-screen-hide-app-content/
💻 Demo: https://github.com/capawesome-team/capacitor-privacy-screen-demo

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.

Hey everyone!

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.

Docs: capawesome.io/docs/sdks/capacitor/mlkit

Happy to answer any technical questions, and if you build something with them, I'd honestly love to see it. Feedback and issues welcome on GitHub. 💜

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.

Full writeup with the GitHub Action setup: https://capawesome.io/blog/share-mobile-app-builds-with-testers/

How much time would this save your team's dev workflow? Curious if anyone's already doing something similar with a custom script.

Capawesome just shipped an official Tauri platform for Capacitor apps.

Basically if you've got a Capacitor app for mobile, you can now add Tauri as a desktop target and get macOS/Windows/Linux builds through the system webview instead of pulling in Electron. Installers end up around 3-10MB, and it generates deny-by-default capability files automatically based on what plugins you're using.

Real limitation though: no arbitrary native plugins, since Tauri has no Node runtime. Only built-in stuff, a curated plugin set, and anything with a web fallback actually run. Also no OTA updates for the web bundle, it gets compiled into the binary, so updates mean shipping a new signed build.

If you need more than that, like OTA updates or the full native plugin ecosystem, there's also a sibling Electron platform. Bigger installers, but way fewer limitations.

So the Tauri one specifically is more for teams with an existing Capacitor codebase who want a lean desktop option and don't mind the tradeoffs.

Curious if anyone here would actually find this useful.

Repo: https://github.com/capawesome-team/capacitor-tauri

If you're releasing Capacitor apps regularly, you've probably updated the version in package.json and then realized you still had to update Android and iOS.

We built Capver to make that a one-command task.

capver patch
capver minor
capver major

It automatically keeps your app version in sync across your web project, Android, and iOS.

It's open source if anyone wants to try it:
https://github.com/capawesome-team/capver

Feedback and feature ideas are always welcome. 🙌🏽

I updated a project to SPM and now when Validating the app through xcode I get all these warnings.

Using Xcode 26.1.1
Already checked the Debug Information Format for app target and set it to DWARF with dSYM File (Debug + Release)

The archive still validates and uploads to App Store Connect.

Has anyone managed to get through this?

I work as a Developer Advocate helping people ship web apps as native mobile apps, and I kept answering the same questions over and over. So I wrote a guide that summarizes everything I recommend, based on 13+ years working in mobile development.

From what I've seen, every time someone in a web dev community asks "how do I publish my React/Vue/Angular app to the App Store?", the answers are either "just make a PWA" (which doesn't actually get you on the stores) or links to tutorials that assume you already know what a provisioning profile is and have Xcode configured on a Mac.

This one starts from zero. It's structured as an index, not a wall of text. Each step links to specific posts, videos, tools, and automation resources so you can go as deep as you need, at your own pace.

Some things I cover that I rarely see explained well:

- Why PWAs won't get you into the App Store or Google Play (and what to use instead)

- How to generate iOS certificates directly from your browser, without a Mac or Keychain Access

- The Google Play closed testing requirement that blindsides most first-time publishers: personal accounts created after November 2023 need 12 testers actively opted in for at least 14 consecutive days before you can go public.

- Why you should install the Live Update plugin in your very first release, even if you have nothing to update yet. Adding it later means another full native build and another review cycle, which is the last thing you want when you're trying to push a critical fix.

- How to build for iOS without owning a Mac

Honest feedback welcome: is there a step that's unclear, or something you think is missing?

https://capawesome.io/blog/11-steps-to-get-your-web-app-on-the-app-store/

Am I the only one surprised by how many mobile developers still don't know OTA updates exist?

I regularly see people still complaining about App Store review times when they need to push a fix or make a UI change... I wonder if they know there're OTA update solutions that have been around for years.

Obviously you can't ship native code changes this way, but for a lot of UI and business logic updates, you don't necessarily need to wait for store approval.

Why do you think OTA updates still aren't more widely known or adopted? Is it policy concerns, lack of awareness, or something else?

How many of you are familiar with this concept?

For anyone unfamiliar with OTA updates, here's a good overview.

Been using Capacitor and Ionic since the early days, built and shipped multiple production apps with it. Ionic Developer Expert. Currently working as a Developer Advocate at Capawesome.
Ask me anything about building, shipping, plugins, app store releases, OTA updates, native integrations, etc.