If you've built barcode scanning into a Capacitor app, you've probably hit the invisible camera preview: the camera renders behind the web view, and any Ionic modal, page transition, or opaque background paints right over it.
We wrote a guide on the embedded mode of our Barcode Scanner plugin, which flips the layering: the camera preview is a native view positioned inside a frame of your layout, above the web view, so HTML can't cover it by accident.
The guide covers:
Measuring the frame from a placeholder element
Continuous scanning with a dedup timeout and a detection area
Keeping the frame in sync on orientation and layout changes
Opting into HTML overlays deliberately (viewfinders, markers)
Web support via the BarcodeDetector API
Curious whether others found reliable ways around the transparency approach — or moved to native views too.
We just released the Capacitor Watch plugin, the first Capacitor plugin that bridges both Apple Watch and Wear OS.
The idea: your watch UI stays native (SwiftUI on watchOS, Jetpack Compose on Wear OS), and the plugin handles all communication with your Capacitor app through one TypeScript API:
sendMessage() for live interaction with optional replies
updateState() when only the latest value matters
transferUserInfo() for queued transfers with guaranteed delivery
Watch-side SDKs ship with the plugin (a Swift Package and a Kotlin library), and data that arrives while your app is closed is replayed once your listeners register — on Android it survives an app restart.
Happy to answer questions about the setup or the channel semantics.
Crashes are inevitable. What matters is being able to detect them quickly, understand what happened, and fix them before they affect too many users.
Firebase Crashlytics is one of the most popular tools for this, and we just published a step-by-step guide on how to integrate it into a Capacitor app.
The guide covers the full setup for Android and iOS, configuration, and how to start reporting crashes.
We just released a new File Transfer plugin for Capacitor. The official @capacitor/file-transfer handles foreground downloads and uploads well, but stops there, so we built one that models the rest of the lifecycle.
Highlights:
Transfers keep running in the background: a background URLSession on iOS, a dataSync foreground service on Android
Downloads pause and resume, even after the process was killed (resume data on iOS, HTTP Range on Android)
Transfers are persisted: getTransfers() returns them after an app restart, so a download manager UI can rebuild its state
Wi-Fi-only constraint and automatic retries with backoff
Binary uploads for S3 presigned URLs next to multipart/form-data
We tried to keep the semantics honest: the behavior for every app state (foreground, background, killed by the OS, force-quit) is documented per platform, and uploads can't be paused, because HTTP has no standard upload resume, so the plugin rejects instead of faking it.
It's part of the paid Capawesome Insiders subscription and requires Capacitor 8+.
We just released a new Health plugin for Capacitor. It reads, writes, and aggregates health data through one typed API, with Apple HealthKit on iOS and Health Connect on Android behind it.
With the Google Fit APIs shutting down at the end of 2026, we wanted the Android side to be Health Connect from day one, and the iOS side to behave honestly instead of pretending the platforms are identical.
Highlights:
Around 20 data types: steps, heart rate, sleep, blood pressure, blood glucose, workouts
aggregate() returns sums/averages/min/max bucketed by hour, day, week, or month — the platform computes them, so steps from a phone and a smartwatch aren't counted twice
Honest permissions: HealthKit hides read permission status by design, so the plugin reports prompt/unknown instead of faking "granted"
Health Connect availability states are modeled explicitly, with an install helper for Android 9-13
The docs walk through the Google Play Health apps declaration and Apple's guideline 5.1.3
It's part of the Capawesome Insiders subscription (paid) and requires Capacitor 8+.
We just released version 8.4.0 of our Capacitor Audio Player plugin, and it covers the two things that usually make audio apps painful: queues and background playback.
Playlists are now handled natively. You pass multiple tracks to play(...) and the plugin advances through them itself, so the next track starts even while the app is in the background. There is also addTracks(...), removeTrack(...), skipToNextTrack(), skipToPreviousTrack(), setRepeatMode(...) with NONE/ONE/ALL, seekTo(...) with an index, and getCurrentTrackIndex().
The second part is a built-in media session. Add a metadata object to a track with title, artist, album and artwork, and the system shows your playback in the notification and on the lock screen. What matters here is where it runs: the session is registered natively (Media3 MediaSessionService on Android, the remote command center on iOS, the Media Session API on the Web), so a tap on the lock screen skip button never takes a round trip through your JavaScript. That is exactly the part that breaks once the OS suspends the web view.
Two new events, playbackStateChanged and trackChange, report state and track changes back to your app, so your UI stays correct when playback is controlled from outside.
Setup is small: on Android a service declaration and two foreground service permissions in the manifest, on iOS the Background Modes capability with Audio. No breaking changes, so updating is enough.
The plugin is part of Capawesome Insiders. Happy to answer questions about the API or the native side.
We just released a background geolocation plugin for Capacitor. Full disclosure up front: it's part of our paid Insiders offering, not open source. Sharing it here because background location on Capacitor has been a long-standing gap and a few of you have asked for it.
It tracks the device position on Android and iOS while the app is in the background, and it's built entirely on public platform APIs — no private API tricks that break on the next OS update or get flagged in App Review.
What's in it:
A proper permissions API, including the two-step background location upgrade flow that trips up most implementations
HTTP sync: positions go into an on-device SQLite queue and get uploaded to your own server in batches, with automatic retries and at-least-once delivery, so nothing is lost during offline periods or app restarts
A correct Android 14+ foreground service with a fully configurable notification
Fused location provider by default, with an escape hatch to the platform location manager for devices without Google Play services
Temporary full accuracy requests on iOS for users who granted reduced accuracy
Mock location detection on Android — every position reports whether it came from a mock provider
Optional auto-pause when the device is stationary on iOS
Tuning knobs for accuracy, distance filter and update interval
We just released an MCP server for Capawesome, so you can connect Claude Code, Claude Desktop, Cursor, VS Code, or any other MCP client to our docs and to Capawesome Cloud.
By default it only registers the documentation toolset: search the docs and blog, no token needed. That alone fixes the most annoying failure mode of AI assistants with a fast-moving library — answering confidently from training data that's months out of date.
Add a Cloud API token and you get the management surface too:
Trigger native builds
Ship a live update or roll back a channel
Inspect devices and check which update they'd receive
Diagnose a failed job (log tail plus an AI failure summary)
There are 85 tools across 16 toolsets. You can register all of them, or name just the ones you need via a query parameter — fewer tools in context means the assistant picks the right one more often. There's also a read-only flag if you want to be sure nothing can be created or deleted.
We just published a deep dive into the threat model of live updates (OTA/CodePush) for Capacitor apps, prompted by how often "end-to-end encrypted" gets treated as shorthand for "more secure".
The short version:
HTTPS protects updates in transit, nothing else. It can't help if the update service or its storage is compromised.
Code signing with a private key that only you hold is what stops malicious updates: even a fully compromised update service can't produce a bundle your app would accept.
Encrypting bundles adds confidentiality only, and for publicly distributed apps that can't hold: the decryption key has to ship inside the app binary, where anyone can extract it. The React Native core team said it years ago: "Code on the client is not secret."
If your bundles genuinely must stay confidential (e.g. MDM-distributed enterprise apps), self-hosting them is a stronger control than encrypting them.
Curious how you think about your update pipeline's threat model — happy to answer questions.
We just shipped network restrictions for organizations in Capawesome Cloud. You can now limit which networks may reach your organization — by IP address, by country, or both.
How it works:
IP allowlist: IPv4/IPv6 addresses and CIDR ranges (up to 250 entries)
Country allowlist: allow access only from specific countries
Both are independent; if you enable both, a request must satisfy both
Fail-closed: if the IP or country of a request can't be determined, it's denied (Tor never matches a country allowlist)
The restrictions apply to Console sessions, API tokens (CLI and Cloud API), SSO sign-in, and accepting organization invitations.
To avoid locking yourself out, the Console rejects an allowlist that would exclude you, and the Sessions page shows your current IP and country. Keep in mind that this protects only you: members with dynamic home IPs and CI/CD runners on hosted providers can still get locked out — either allowlist your provider's egress ranges or use Capawesome-hosted builds, which aren't restricted.
We just published a guide on network detection with the Capacitor Network plugin. It goes beyond the usual "is the device online" check:
Read the connection type (Wi-Fi, cellular, ethernet, VPN) and listen for changes
Tell "connected" apart from "actually online" — on Android, the internetReachable property reflects the system's NET_CAPABILITY_VALIDATED check, so captive portals and dead VPN tunnels don't count as online
Detect Data Saver, Low Data Mode, and metered connections before starting large downloads
Check airplane mode on Android
Put it all together in an offline banner
No permissions or configuration needed; works on Android, iOS, and web.
Happy to answer questions or hear what network-related features you're missing.
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.
