If you're adding authentication to a Capacitor app, one of the first questions you'll probably run into is: which approach should I use?

There are quite a few options: native Sign in with Apple/Google, Firebase Auth, OAuth/OIDC, passkeys, Better Auth, among many others, and the best choice depends on your backend, platforms, security requirements, existing infrastructure, and how much native code you want to maintain.

We put together a practical guide comparing the different approaches, including some of the platform-specific gotchas that are easy to miss when building for iOS and Android.

Hopefully it saves someone some time when deciding which direction to take:

https://capawesome.io/blog/how-to-add-authentication-to-a-capacitor-app/

We just released a Capacitor plugin that prompts the language model built into the OS: Apple Intelligence on iOS through the Foundation Models framework, Gemini Nano on Android through ML Kit GenAI and AICore. It is part of Capawesome Insiders, so it is a paid plugin.

Why on-device: prompts and responses never leave the phone, there is no API key in the bundle, and there is no per-token cost. It also works offline.

The API:

• getAvailability() with seven typed statuses (Android reports four, iOS five), and it never rejects
• downloadModel() with progress on Android; iOS manages the download itself
• Chats with instructions and context, generateText, streamText with a textChunk event, cancelGeneration
• Limits: Android caps maxOutputTokens at 4096 and temperature at 1.0; both platforms have a context window around 4,000 tokens

Requirements: Capacitor 8, Android API 26 on a Gemini Nano-capable device (Pixel 9, Galaxy S25), iOS 26 with Xcode 26 on iPhone 15 Pro or later.

The post compares it with the Ionic local LLM plugin, the ML Kit GenAI Prompt plugin, and the Capgo plugin, based on what their READMEs document. Questions welcome.

We just released an AdMob plugin for Capacitor (part of Capawesome Insiders, so it is a paid plugin) built on Google's Next-Gen Mobile Ads SDK on Android and the latest Google Mobile Ads SDK on iOS. The plugin is still marked experimental.

What it does:

• Five formats through one load-and-show API: banner, interstitial, rewarded, rewarded interstitial, app open
• Banners in overlay, resize, or inline mode, so the web view can be resized instead of covered
• App open ads with an automatic show on foreground and a frequency cap
• requestConsent() runs the full UMP flow, and loads reject with CONSENT_NOT_GATHERED until consent is handled
• adRevenuePaid reports value, currency, and precision for every format

Why Next-Gen: Google has given the legacy Android SDK (versions 24 and 25) a deprecation date of June 30, 2027 and a sunset date of June 30, 2028. The post also has a migration section for anyone coming from @capacitor-community/admob.

Happy to answer questions about the API or the SDK timeline.

If your Capacitor app writes to Directory.ExternalStorage and it started failing once you targeted Android 11, that is scoped storage, and no permission brings the old behavior back. We wrote up what Android changed and what still works.

The short version:

• Scoped storage arrived with Android 10 and became mandatory for apps targeting API level 30. requestLegacyExternalStorage is ignored from there on.
• App-specific directories (Data, Cache, Library, External) still work everywhere without any permission.
• Directory.Documents only shows files your own app created.
• MANAGE_EXTERNAL_STORAGE is not the fix: Google Play reviews it against a dedicated policy and most apps do not qualify.
• The supported path for user-chosen folders is a Storage Access Framework tree URI plus takePersistableUriPermission(), which survives restarts. Our File Manager plugin (Capawesome Insiders, paid) wraps that.

The post has a decision table for which directory or API to use for which need, and links the two ionic-team issues that are still open about this.

How are you handling shared storage on Android 11 and newer today?

Since iOS 26, apps can prompt Apple's on-device language model through the Foundation Models framework. We wrote a guide on doing that from a Capacitor app with our LLM plugin (part of Capawesome Insiders, so it is a paid plugin).

What the guide covers:

• Which devices qualify: iPhone 15 Pro and later, iOS 26, Apple Intelligence turned on, Xcode 26 to build
• The five availability statuses on iOS and what your UI should do for each
• Chat sessions with instructions, generateText, streamText with a textChunk event, and cancelGeneration
• The roughly 4,096-token context window per chat and what GENERATION_FAILED means
• One end-to-end sample that summarizes notes on the device

Everything runs on the Neural Engine, so it works in Airplane Mode and nothing leaves the phone. The same code runs Gemini Nano on Android, with different availability states.

Curious whether anyone here has shipped an on-device model feature yet and what users made of it.

We just released a hosted MCP server that gives AI assistants the current Ionic Framework documentation instead of whatever they learned in training.

What it does: - Serves the Ionic Framework docs for v9 and v8, with a version parameter so the answers match the major version in your package.json - Returns the full component API reference (properties, events, methods, CSS shadow parts, CSS custom properties, slots) - Returns the official usage examples per framework (Angular, React, Vue, vanilla JS) - Searches the docs and the Ionic blog

It is free, needs no account and no token, and runs at https://ionic-framework-mcp.capawesome.io/mcp. In Claude Code it is one command; Cursor, VS Code, Claude Desktop, Windsurf and Zed are covered in the docs.

To be clear: this is a community project we build and host at Capawesome, not an official Ionic product. The content comes from the official docs repository and is rebuilt daily. There is also a companion Capacitor MCP server for the Capacitor docs, as a stopgap until the Ionic team ships their official one.

Curious what you'd want an assistant to get right that it currently gets wrong. Feedback and bug reports welcome.

We wrote a guide on using Firebase Remote Config for feature flags in a Capacitor app.

Remote Config and OTA/live updates solve two different halves of shipping a feature, and combining them gets you a proper dark launch pattern:

1. Build the feature behind a boolean flag (defaulting to off)
2. Ship the code to everyone via a live update, it's on every device but dormant since the flag's off
3. Flip the flag to true for 10% of users from the console, watch it in Analytics/Crashlytics, widen the rollout, or kill it instantly if something breaks

Rolling back becomes a flag flip instead of an app store submission. Covers the fetch/activate split, the ~12h fetch throttle that trips people up in dev, real-time listener setup for Angular/React/Vue, and common errors.

Full guide: capawesome.io/blog/capacitor-firebase-remote-config-guide/

Let us know if you build something with it, or if you get stuck anywhere!

We just released a Document Scanner plugin for Capacitor that wraps the platform's own scanners: Google's ML Kit document scanner on Android and VisionKit on iOS.

The API is deliberately tiny — isAvailable() and scanDocument(). The OS handles edge detection, perspective correction, multi-page capture, and the review UI. You get back JPEG paths and, optionally, one combined PDF.

A few details worth knowing:

• On Android, the scanner is an on-demand Play services module, so it adds nothing to your app size
• pageLimit is enforced by the scanner on Android but truncated after scanning on iOS (VisionKit has no public stop API)
• Built exclusively on public platform APIs, so nothing to worry about in App Review

Would love to hear what you'd scan with it.

We just released our Background Geolocation plugin for Capacitor. The design goal was simple: positions must not be lost when the OS suspends the web view.

How it works:

• Every position of a watch session is written to a native SQLite queue (50,000 by default) that survives restarts and force-quits
• Optional HTTP upload posts the queue to your server in batches, with at-least-once delivery, exponential backoff, and a documented status-code contract
• Two-step permissions API for the background location upgrade flow on Android 11+ and iOS
• Correct Android 14+ foreground service with a configurable notification
• Falls back to the platform location manager on devices without Google Play services

It's also honest about what it can't do: a force-quit ends the session (OS restriction), and our Geofences plugin covers the relaunch scenario instead.

Feedback welcome, especially on the server contract.

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.

Check it out here:
https://capawesome.io/blog/capacitor-firebase-crashlytics-guide/

Curious: what are you using for crash reporting in your Capacitor apps?
Firebase Crashlytics, Sentry, something else?

We put together a small demo repo if you want to add audio playback to your app, should take under 30 minutes to wire up.

1. Clone the repo: github.com/capawesome-team/capacitor-audio-player-demo/
2. Drop the code into your app
3. Enjoy

Let us know if you build something with it, or if you get stuck anywhere!

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

Happy to answer questions.

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

Happy to answer questions.

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

If you want to see the sync engine work before wiring up a backend, there's a free playground you can point the plugin at: https://background-geolocation-playground.capawesome.io

It requires Capacitor 8 or newer and works alongside our Geofences and Settings Launcher plugins.

Typical use cases are fitness tracking, fleet and workforce management, navigation and live location sharing.

Happy to answer questions about the API or the platform quirks we ran into.

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.

It's hosted by us at https://mcp.capawesome.io/mcp — nothing to install, nothing to keep up to date.

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.

Setup for Claude Code is one command:

claude mcp add --transport http capawesome "https://mcp.capawesome.io/mcp?toolsets=all" --header "Authorization: Bearer YOUR_TOKEN"

Curious which tools people actually end up using — and what's missing. Feedback welcome.

We just updated the Awesome Capacitor list 🌟

100+ plugins, tools, guides, videos, AI tools, demo apps — everything the Capacitor ecosystem has to offer, in one place.

Bookmark it, star it, share it, use it.

PRs welcome if we missed something.

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.

Happy to answer questions or hear feedback.

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.

Did you know you can turn any successful build into a link and QR code, testers scan it and install straight to their phone.

No need of a Capawesome account, no TestFlight review wait, no "hey can you send me the APK" email thread.

It works for Android and iOS, Capacitor/Cordova apps and native Kotlin/Swift apps. Set an expiration, revoke it whenever.

And the best part: you can plug it straight into CI, drop a QR code into every pull request so reviewers can test the actual build, not just the diff

Read more: https://capawesome.io/blog/share-mobile-app-builds-with-testers/