DEV Community: Capawesome

Google Play Contacts Policy 2027 for Capacitor

Robin — Thu, 13 Aug 2026 16:45:02 +0000

Google Play's new Contacts Permissions policy takes effect on January 27, 2027. Apps that target Android 17 (API level 37) or later may only declare READ_CONTACTS if the Android Contact Picker cannot cover their core functionality. If your Capacitor app only lets users pick a contact, you need to drop the permission, and with the Capacitor Contacts plugin that means passing the property option to pickContacts(...).

There is a catch that Google's announcement doesn't mention. Switching to the system contact picker does not by itself free you from READ_CONTACTS. Below Android 17, the picker hands your app an access grant so narrow that it contains no phone number, no email address, and no structured name (only a display name). This guide covers what the policy requires, why the picker alone falls short, and how to select a contact detail without ever asking for the permission.

Key Takeaways

Google Play's Contacts Permissions policy was announced on April 15, 2026 and becomes effective on January 27, 2027.
It applies to apps that target Android 17 (API level 37) or later. Those apps may only request READ_CONTACTS if the Android Contact Picker is not sufficient for their core functionality.
Apps that still need broad access must submit a Play Console declaration naming the features that require it and explaining why the picker falls short.
The contact picker grants read access to the picked contact URI only. That URI exposes no phone numbers, email addresses, or structured name, so reading contact details still requires READ_CONTACTS below Android 17.
The property option of pickContacts(...) lets the user select a single phone number, email address, or postal address. It requires no permission on any Android version and is available since version 8.1.0 of the Capacitor Contacts plugin.
On iOS, pickContacts(...) has never required a permission.

What Does Google Play's Contacts Permissions Policy Require?

The policy reserves READ_CONTACTS for apps that genuinely cannot work without the full address book. Google's wording is that apps which don't need broad access "must use the Android Contact Picker, a more secure, easy-to-integrate alternative that minimizes data collection and improves user safety."

Three details decide whether this affects you:

Who it applies to. Only apps that target Android 17 (API level 37) or later. Since Google Play raises the required target API level every year, that will be every actively maintained app soon enough.
When it lands. Google announced the policy on April 15, 2026 and set the effective date to January 27, 2027. Pre-review checks in the Play Console start on October 27, 2026, so you will see warnings before enforcement begins.
What the escape hatch costs. Apps that need ongoing access to the whole contact list keep it, but they have to file a Play Developer Declaration that names the user-facing feature and explains why the picker is technically insufficient. Automatic 30-day extensions are available through the Play Console.

A messaging app that syncs your address book to find friends has a case to make. A checkout screen that fills in a delivery address does not, and that second group is where most Capacitor apps sit.

Why Does the Contact Picker Still Need READ_CONTACTS?

Because the permission grant the picker returns is narrower than the data you asked for. When the user selects someone, the system grants your app read access to the picked contact URI, and that grant is exact: it covers that one URI and nothing below or beside it.

The problem is what lives at that URI. A row in the Contacts table holds an identifier and some metadata. It holds no phone numbers, no email addresses, and no structured name, because in Android's contacts model those live in the separate ContactsContract.Data table. Querying that table is a global read, and the grant does not extend to it. It does not extend to the contact's entities sub-directory either. Attempt it without the permission and the provider answers with a flat refusal:

Permission Denial: reading ContactsProvider2 uri content://com.android.contacts/contacts/1/entities requires android.permission.READ_CONTACTS

So "use the picker instead of the permission" is only half an instruction below Android 17. The picker gives you a contact you are allowed to identify but not allowed to read. There is no permission-free way to pull a whole contact record on those versions, which is why the plugin needs a different approach rather than a different intent.

How to Pick a Contact Without the READ_CONTACTS Permission

Ask the picker for a single contact property instead of a whole contact. The property option of pickContacts(...) launches the picker against the phone, email, or postal address table directly, so the user selects one specific value rather than a person:

import { ContactProperty, Contacts } from '@capawesome-team/capacitor-contacts';

const pickPhoneNumber = async () =&gt; {
  const { contacts } = await Contacts.pickContacts({
    property: ContactProperty.PhoneNumber,
  });

  return contacts[0]?.phoneNumbers?.[0]?.value;
};

This works because the picker now returns a data row URI, and the access it grants points at the row that actually holds the value. Your app reads it directly, on every Android version, without a permission in the manifest and without a runtime prompt. To install the Capacitor Contacts plugin, please refer to the Installation section in the plugin documentation.

ContactProperty offers three values, matching the three data tables the system picker can target:

Value	Selects	Read from
`ContactProperty.PhoneNumber`	A single phone number	`phoneNumbers`
`ContactProperty.EmailAddress`	A single email address	`emailAddresses`
`ContactProperty.PostalAddress`	A single postal address	`postalAddresses`

The result is deliberately thin. You get the contact id, the new displayName property, and the property the user picked, and nothing else:

const { contacts } = await Contacts.pickContacts({
  property: ContactProperty.EmailAddress,
});

const contact = contacts[0];

console.log(contact.displayName); // 'John Doe'
console.log(contact.emailAddresses?.[0].value); // 'john.doe@example.com'

displayName is a read-only property added in version 8.1.0. It holds the formatted name the device itself shows for the contact, derived from CNContactFormatter on iOS and Data.DISPLAY_NAME on Android, and it is the only name the granted URIs expose. Setting it when creating or updating a contact has no effect, so keep using givenName and familyName for that.

Practically, this changes how you design the interaction. Instead of one "Choose a contact" button followed by a disambiguation dialog when someone has four phone numbers, you send the user straight into a picker that lists the numbers. Fewer taps for them, no permission prompt for you.

What Changes on Android 17?

Android 17 makes plain contact picking permission-free on its own. Apps targeting API level 37 get their ACTION_PICK intent automatically upgraded to the new system contact picker, which returns a picker session URI following the ContactsContract.Data schema. The plugin detects that URI and reads it directly, so a call to pickContacts(...) without the property option also stops needing READ_CONTACTS there.

That does not make the property option redundant. Your app still runs on Android 16 and below, where the old behavior applies, and you cannot ship a manifest that declares READ_CONTACTS on old devices but not on new ones. As long as you support anything below Android 17, the property option is what lets you leave the permission out entirely.

When Do You Still Need READ_CONTACTS?

Whenever your app reads the address book without the user pointing at a specific entry. Every method that queries contacts on its own terms falls in this group:

getContacts(...) and getContactById(...), which read the address book directly.
countContacts(), getGroups(), and getAccounts().
Anything that syncs, backs up, or matches the full contact list against a server.

If your app does one of these as a core feature, the policy does not shut you out. Keep the permission and file the declaration. What the policy targets is the app that declares READ_CONTACTS to power a single "pick a friend" screen, and that app now has a cheaper option.

Two methods need no permission at all and are worth knowing about: displayCreateContact(...) hands the whole creation flow to the system UI, and on iOS pickContacts(...) has always run without one, because CNContactPickerViewController returns the selected contact to the app without touching the contacts entitlement.

How to Migrate Your Capacitor App

Work through it in this order:

Find every contacts call in your codebase. Search for Contacts. and sort the hits into two buckets: user-driven selection, and everything else.
Rewrite the selection calls. Replace pickContacts() with a property variant and adjust the code that consumes the result, since it now receives one value instead of a full contact object.
Decide about the rest. If the second bucket is empty, you are done and the permission can go. If it isn't, check whether those features are genuinely core to your app or leftovers you can drop.
Remove the permission. Delete `from yourAndroidManifest.xml. LeaveWRITE_CONTACTS` alone if you create or update contacts, as this policy does not cover it.
Test on a real device. Build with the permission removed and run every flow that touches contacts. A missing grant surfaces as a Permission Denial in Logcat, not as a friendly error, so watch the log while you click through.
File the declaration if you kept the permission. Do it before pre-review checks start on October 27, 2026 rather than in the week before the January deadline.

FAQ

When does Google Play's Contacts Permissions policy take effect?

January 27, 2027. Google announced it on April 15, 2026, and pre-review checks in the Play Console begin on October 27, 2026, which gives you roughly three months of warnings before enforcement. Automatic 30-day extensions can be requested through the Play Console.

Does the policy apply if my app targets Android 16?

Not yet. The policy covers apps that target Android 17 (API level 37) or later. Google Play raises the minimum target API level for updates every year, though, so an app that is still maintained will reach API 37 on its own schedule. Migrating early costs less than migrating under a deadline.

Does this affect my app on iOS?

No. This is a Google Play policy and applies to Android only. On iOS, pickContacts(...) never required the contacts permission, and the property option behaves the same way there, returning the id, the displayName, and the selected property.

Can I still read a full contact after the user picks one?

Only with READ_CONTACTS below Android 17. The picker's grant covers the picked contact URI, which carries no phone numbers, email addresses, or structured name, and reading those means querying the ContactsContract.Data table, which the grant does not cover. From Android 17 on, the upgraded system picker returns a data-schema URI that the plugin reads without the permission.

What happens if I keep READ_CONTACTS without filing a declaration?

Once the policy is effective, apps targeting Android 17 or later that declare the permission without an approved declaration are subject to enforcement, which in practice means your app updates get blocked in the Play Console. The declaration itself asks which user-facing features need the permission and why the Android Contact Picker is technically insufficient.

Does the property option work on older Android versions?

Yes. Picking against the phone, email, or postal address table is not an Android 17 feature. The picker returns a data row URI it grants access to on every supported Android version, which is exactly what makes the option a safe way to remove the permission from your manifest today.

Conclusion

The migration is smaller than the policy makes it sound. For most Capacitor apps it comes down to one option on one method call and one line deleted from the Android manifest. What takes the thinking is the audit: knowing which of your contacts calls are user-driven selection and which ones read the address book on their own, because only the second group needs a declaration.

For a full tour of the plugin's API, from permissions to accounts and groups, read Exploring the Capacitor Contacts API. If you have questions, join the Capawesome Discord server, and subscribe to the Capawesome newsletter to stay up to date with new plugins and guides.

Capacitor Live Updates: Signing vs Encryption

Robin — Wed, 12 Aug 2026 13:00:43 +0000

If you compare live update solutions for long enough, you will run into a security claim that sounds decisive: "end-to-end encrypted." It suggests that solutions offering encryption are more secure than solutions that "only" sign their updates. That framing mixes up what the individual security controls in an update pipeline actually do. In this post, we walk through the threat model of live updates (also known as OTA updates or CodePush): what HTTPS already protects, what code signing guarantees, what encryption adds on top, and which of these properties matter for your app. By the end, you can evaluate the security of any live update solution based on facts instead of buzzwords.

Key Takeaways

HTTPS protects update bundles in transit. It does not protect against a compromised update service, storage bucket, or CDN.
Code signing with a developer-held private key guarantees authenticity and integrity all the way to the device: even a fully compromised update infrastructure cannot inject code into your app.
Encrypting bundles adds confidentiality only. It provides no additional protection against malicious updates.
Client-side encryption cannot keep app code secret, because the decryption key must ship inside the app binary. The React Native maintainers state it plainly: "Code on the client is not secret."
If bundles must stay confidential, for example in privately distributed enterprise apps, self-hosting them is a stronger control than encrypting them.

The Trust Chain of a Live Update

Every live update passes through the same chain: you build a web bundle in your CI/CD pipeline, upload it to an update service, the service stores and serves it (usually through a CDN), and the Live Update SDK in your app downloads and installs it. Security along this chain means three different properties:

Authenticity: The update genuinely comes from you.
Integrity: The update was not modified on the way.
Confidentiality: No third party can read the update's content.

For code that ends up running on your users' devices, authenticity and integrity are non-negotiable. A single malicious bundle can compromise every device that installs it. Confidentiality plays a much smaller role than most marketing suggests, and we will look at why below.

What HTTPS Already Protects

HTTPS encrypts and authenticates the connection between the device and the server it downloads from. It reliably prevents on-path attackers, for example on public Wi-Fi or at the ISP level, from reading or modifying an update in transit.

What HTTPS cannot do is vouch for the endpoints themselves. It says nothing about what happened to a bundle before it entered the pipe: if the update service, its storage, or its CDN is compromised, HTTPS will faithfully deliver the attacker's bundle with a valid certificate. Every serious live update solution uses HTTPS, so transport security is not where solutions differ.

What Code Signing Protects

Code signing guarantees both authenticity and integrity, independent of the infrastructure in between. You sign each bundle with a private key when uploading, typically in your CI/CD pipeline, and the app verifies the signature with an embedded public key before applying the update. If verification fails, the update is discarded and the app keeps running its current bundle.

This is the control that addresses the threat that actually matters: a compromised update pipeline. Because the private key stays with you, for example in your CI/CD secret store, an attacker who took over the update service, the storage, or the CDN still could not produce a bundle your app would accept. With code signing enabled, you don't have to trust your update provider to be uncompromised.

Capawesome Cloud implements this with a standard RSA key pair. You generate the pair with the Capawesome CLI, keep the private key, and embed the public key in your app. Signing then happens as part of the upload:

npx @capawesome/cli apps:liveupdates:upload --private-key private.pem

Verification on the device fails closed, and protected channels require signed bundles. You can find the full setup in the Code Signing documentation.

Do Live Updates Need End-to-End Encryption?

For most apps, no. End-to-end encryption of update bundles adds exactly one property: confidentiality toward the update service and its storage. It adds nothing to authenticity or integrity that code signing does not already provide, so it does not make updates any harder to forge or tamper with.

The deeper problem is that confidentiality of app code is not achievable for a publicly distributed app. Your web bundle is delivered to every user's device, where it is stored and executed, and anyone can download your app from the App Store or Play Store and read it with freely available tools. For the app to decrypt updates, the decryption key must ship inside the app binary, so anyone can extract that key too, including any party the encryption was meant to keep out. The React Native core team declined to add bundle encryption to the framework for exactly this reason: "Code on the client is not secret - secrets should be kept on the server."

A live update solution that combines HTTPS with developer-held code signing already guarantees that nobody, including the update service itself, can modify your updates or inject code into your app. Encryption on top of that does not make a solution more secure for a public app; it addresses a property that public distribution gives up by design.

There are legitimate niches. If your app is distributed privately, for example through mobile device management (MDM) in an enterprise, outsiders cannot obtain your binary, and encrypting bundles genuinely keeps their content away from the update provider. Encryption can also limit the impact of a storage breach while a bundle is staged but not yet rolled out. If those scenarios are part of your threat model, though, there is a control that solves them more thoroughly.

When Confidentiality Matters: Self-Host Your Bundles

Instead of encrypting bundles so that a third party cannot read them, you can remove the third party from the data path entirely. Capawesome Cloud supports self-hosting bundles: your bundles stay on your own servers, and only the metadata required to check for updates is exchanged with the Cloud. Devices download bundles directly from your infrastructure over HTTPS.

Code signing works the same way as with hosted bundles, so you keep the authenticity and integrity guarantees on top of full confidentiality. No encryption scheme with an extractable key can match a setup where the provider never holds the artifact at all. Self-hosting is also the answer to data residency and compliance policies that prohibit sharing build artifacts with third parties.

Live Update Security Best Practices

Beyond choosing a solution with the right controls, most of your security posture comes down to how you configure it:

Enable code signing in production. It is the single control that protects you even if the update infrastructure is compromised. Follow the Code Signing guide to set it up.
Guard your private key. Store it in your CI/CD secret store and never commit it to version control.
Use protected channels. Protected channels require signed bundles, so an unsigned bundle can never slip through.
Keep secrets out of bundles. Treat every bundle as public. API keys and credentials belong on your server, whether or not your update pipeline encrypts anything.
Roll out gradually and be ready to roll back. Gradual rollouts limit how many devices a bad update can reach, and rollbacks let you recover in minutes.
Self-host bundles if your policies require it. Self-hosting keeps your artifacts on your own infrastructure without giving up signing.

Capawesome Cloud ships with all of these controls built in, so you can start with a secure setup from day one.

Try Capawesome Cloud Free

FAQ

Is end-to-end encryption more secure than code signing for OTA updates?

They protect different properties, and for publicly distributed apps, code signing covers the one that matters. Signing guarantees that only bundles produced with your private key are ever installed, which protects against compromised update infrastructure. Encryption only hides bundle content from the update provider, and that guarantee is weakened by the fact that the decryption key ships inside every app binary. An update pipeline with HTTPS and developer-held code signing is not less secure because it skips bundle encryption.

Can someone read my live update bundles?

Yes, and you should plan for it. Live update bundles are web assets (HTML, CSS, and JavaScript) that are delivered to and stored on every user's device, so anyone can extract them from your app, with or without encryption in the delivery pipeline. Keep secrets such as API keys on your server and treat everything inside a bundle as public.

What happens if the update service itself is compromised?

With code signing enabled, nothing gets installed. The app verifies every downloaded bundle against your public key before applying it. A bundle that was not signed with your private key fails verification, is discarded, and the app keeps running its current version. This is why the private key must remain under your control.

Does code signing work with self-hosted bundles?

Yes. With Capawesome Cloud, you sign self-hosted bundles when registering them with the CLI, and devices verify the signature after downloading from your server, exactly as with hosted bundles. Combined, self-hosting and code signing give you confidentiality, authenticity, and integrity at the same time.

Are live updates as secure as app store updates?

With code signing enabled, they follow the same trust model. App store updates are signed by the developer and verified by the operating system before installation. Signed live updates are signed with your private key and verified by the Live Update SDK before being applied. In both cases, only code that you produced, unmodified, reaches your users.

Conclusion

When you evaluate the security of a live update solution, match each feature to the property it protects. HTTPS covers the network. Code signing with a key that only you hold covers malicious updates, including the case where the update service itself is compromised. Confidentiality is the outlier: for publicly distributed apps, no client-side encryption scheme can fully deliver it, and where it genuinely matters, self-hosting provides it architecturally. Capawesome Cloud combines all three controls: HTTPS delivery, developer-held code signing with fail-closed verification, and optional self-hosting.

For a look at how signing and verification are implemented on Android and iOS, read How Capacitor Live Updates Work Under the Hood. And since security is only one half of evaluating a provider, our Capacitor live update reliability guide covers the other: uptime claims, SLAs, and rollback plans. Join the Capawesome Discord server if you have questions, and subscribe to the Capawesome newsletter to stay updated on the latest news.

How to Detect the Network Status in a Capacitor App

Robin — Sun, 09 Aug 2026 15:00:14 +0000

To detect the network status in a Capacitor app, install the Capacitor Network plugin, call getStatus() to read the current connection, and attach a networkStatusChange listener to get notified whenever it changes. The plugin tells you whether the device is connected, how it is connected (Wi-Fi, cellular, ethernet, or VPN), and things the browser's navigator.onLine can't: whether the connection has verified internet access, whether it is metered, and whether the user has enabled a data-saving mode.

In this guide, we build network detection up step by step: reading the current status, reacting to changes, telling "connected" apart from "actually online", handling metered and data-saving connections, checking airplane mode, and putting it all together in an offline banner.

Key Takeaways

The Capacitor Network plugin (@capawesome/capacitor-network) reads the network status on Android, iOS, and the web through a single TypeScript API, with no permissions or configuration required.
getStatus() returns the connection state, the connection type (WIFI, CELLULAR, ETHERNET, VPN, SATELLITE, NONE, or UNKNOWN), and flags for constrained, expensive, and ultra-constrained connections.
On Android, internetReachable reflects the system's NET_CAPABILITY_VALIDATED check, so captive portals and dead VPN tunnels don't count as "online".
constrained detects Data Saver on Android and Low Data Mode on iOS; expensive detects metered Wi-Fi and cellular connections.
The device is only observed while at least one listener is attached, so listening for changes doesn't cost battery when you don't need it.

Getting the Current Network Status

Reading the network status takes a single call to getStatus(). To install the Capacitor Network plugin first, please refer to the Installation section in the plugin documentation. Once installed, no configuration is needed; on Android, the plugin already declares the required ACCESS_NETWORK_STATE permission in its own manifest.

import { Network } from '@capawesome/capacitor-network';

const logNetworkStatus = async () => {
  const status = await Network.getStatus();
  console.log('Connected:', status.connected);
  console.log('Connection type:', status.connectionType);
};

The returned GetStatusResult contains more than the two properties above:

connected: whether the device is connected to any network.
connectionType: how it is connected, as a typed ConnectionType enum (WIFI, CELLULAR, ETHERNET, VPN, SATELLITE, NONE, or UNKNOWN).
internetReachable: whether the connection has verified access to the internet (Android only, null elsewhere).
constrained: whether a data-saving mode restricts the connection.
expensive: whether the connection is metered.
ultraConstrained: whether bandwidth is severely limited, for example on a carrier-provided satellite network.

A word on the null values you'll see in some of these properties: the plugin returns null wherever a platform can't determine the answer, instead of guessing. That makes the API honest about platform limits, and it's why the examples below compare against false explicitly rather than relying on truthiness.

Listening for Network Changes

Polling getStatus() is the wrong tool for reacting to connectivity drops; instead, register a listener for the networkStatusChange event and let the plugin push updates to you:

import { Network } from '@capawesome/capacitor-network';

const watchNetwork = async () => {
  await Network.addListener('networkStatusChange', status => {
    console.log('Network changed:', status.connectionType);
  });
};

The listener receives the same GetStatusResult shape as getStatus(), so switching from Wi-Fi to cellular, losing the connection entirely, or entering Low Data Mode all arrive through the same event. The plugin only observes the device while at least one listener is attached, so there is no background cost once you clean up.

When your feature no longer needs updates, remove the listeners with removeAllListeners():

import { Network } from '@capawesome/capacitor-network';

const stopWatching = async () => {
  await Network.removeAllListeners();
};

Why "Connected" Doesn't Mean Online

A device can be connected to a network without reaching the internet. The classic case is a captive portal: hotel or airport Wi-Fi reports a healthy connection, but every request is redirected to a login page until the user signs in. A VPN whose tunnel has silently died behaves the same way. If your app starts a sync the moment connected turns true, both cases produce failed requests and confused users.

This is what the internetReachable property is for. On Android, it reflects the NET_CAPABILITY_VALIDATED capability, meaning the operating system has actually verified that the connection reaches the internet:

import { Network } from '@capawesome/capacitor-network';

const canSync = async () => {
  const { connected, internetReachable } = await Network.getStatus();
  return internetReachable ?? connected;
};

On iOS and the web, internetReachable is always null, because those platforms can't distinguish validated internet access from mere connectivity. The ?? connected fallback above handles that cleanly: use the verified answer where the platform provides one, and fall back to the connection state everywhere else.

Detecting Metered and Data-Saving Connections

Not every connection should be treated equally, even when it works perfectly. Users on metered hotspots or limited data plans don't want your app to pull hundreds of megabytes in the background, and both Android (Data Saver) and iOS (Low Data Mode) let them say so system-wide. The expensive and constrained properties expose exactly these signals, so a download queue can respect them:

import { Network } from '@capawesome/capacitor-network';

const shouldDownloadLargeFiles = async () => {
  const { connected, expensive, constrained } = await Network.getStatus();
  return connected && expensive === false && constrained === false;
};

The strict === false comparisons matter here. Both properties are null on platforms that can't determine them (for example, most browsers), and treating "unknown" the same as "cheap and unrestricted" would defeat the purpose of the check.

Checking Airplane Mode on Android

When the connection type is NONE, it helps to tell the user why. On Android, isAirplaneModeEnabled() answers one common cause directly:

import { Network } from '@capawesome/capacitor-network';

const explainOffline = async () => {
  const { enabled } = await Network.isAirplaneModeEnabled();
  return enabled
    ? 'Airplane mode is on. Disable it to reconnect.'
    : 'You are offline. Check your connection.';
};

This method is Android-only, since iOS offers no public API for reading the airplane mode state and browsers don't expose it either.

Building an Offline Banner

The most common use of network detection is also the simplest: an offline banner that appears when the connection drops and disappears when it comes back. Combining the initial status read with the change listener covers both the app launch and every change afterwards:

import { Network } from '@capawesome/capacitor-network';

const toggleOfflineBanner = (offline: boolean) => {
  document.getElementById('offline-banner')?.classList.toggle('hidden', !offline);
};

const setupOfflineBanner = async () => {
  const status = await Network.getStatus();
  toggleOfflineBanner(!status.connected);

  await Network.addListener('networkStatusChange', status => {
    toggleOfflineBanner(!(status.internetReachable ?? status.connected));
  });
};

The same pattern maps directly to a state variable in Angular, React, or Vue: read once on startup, subscribe for changes, and drive the banner from a single boolean. Note the reachability fallback from earlier reappearing in the listener, so Android users behind a captive portal see the banner even though they are technically connected.

FAQ

What is the difference between `connected` and `internetReachable`?

connected tells you whether the device is on any network at all, while internetReachable tells you whether that network has verified access to the internet. The two disagree behind captive portals and broken VPN tunnels, where the device is connected but nothing gets through. internetReachable is only available on Android and is null on iOS and the web.

How is this plugin different from the official Capacitor Network plugin?

The official @capacitor/network plugin reports the connection state and a basic connection type. The Capacitor Network plugin from Capawesome additionally reports verified internet reachability on Android, data-saving and metered connection flags, satellite and ultra-constrained network detection, an airplane mode check, and distinguishes ethernet and VPN connections as their own connection types.

Do I need any permissions to detect the network status?

No. The plugin works without configuration on all platforms. The ACCESS_NETWORK_STATE permission it needs on Android is declared in the plugin's own manifest, so there is nothing to add to your app.

Does network detection work in the browser?

Yes. On the web, the plugin reads navigator.onLine and the Network Information API where the browser supports it. Properties that browsers can't provide, such as internetReachable, are null there.

Why is a VPN connection reported as `UNKNOWN` on iOS?

On iOS, the plugin reads the network status from the NWPathMonitor of the Network framework, which does not identify VPN tunnels as a distinct interface type. The VPN connection type is therefore only reported on platforms that can detect it, such as Android.

Conclusion

Detecting the network status in a Capacitor app comes down to two calls: getStatus() for the current state and a networkStatusChange listener for everything after. The properties beyond connected are where the real quality wins live: internetReachable keeps captive portals from looking like working connections, and expensive and constrained keep large downloads off networks where they hurt.

There is one connection type we deliberately skipped here: satellite. Detecting it, and adapting your app to its extreme bandwidth limits on Android 15+ and iOS 26, is covered in the Capacitor Network plugin documentation. If you have questions, join the Capawesome Discord server, and subscribe to the Capawesome newsletter to stay up to date with new plugins and guides.

How to Use SQLite in Capacitor Apps

Robin — Sun, 05 Jul 2026 14:05:27 +0000

If you are building a Capacitor app that needs to store more than a few key-value pairs, you will hit the limits of the Preferences API pretty quickly. SQLite is the natural next step: a full relational database that runs on the device, works offline, and handles thousands of rows without breaking a sweat.

In this tutorial, you will learn how to set up a Capacitor SQLite plugin across all four platforms, run queries and transactions, apply schema migrations, use full-text search, encrypt your database, and avoid the most common pitfalls along the way.

Why SQLite for Capacitor Apps?

Capacitor gives you a few options for storing data, but they serve very different purposes:

Storage	Best for	Watch out for
Preferences API	Small key-value pairs (settings, flags)	No queries, no relations, not built for large data
IndexedDB (WebView)	Web-only caching	Can be evicted by the OS under storage pressure
SQLite	Structured, relational, offline-first data	Needs a plugin on native platforms

The decisive difference: SQLite stores data in a real database file on the device's filesystem. It is persistent, fast, queryable with SQL, and battle-tested on every platform. IndexedDB, in contrast, lives in the JavaScript runtime's storage, which the operating system may clean up at any time — not something you want to explain to a user who just lost their offline data.

If your app has lists, relations, sync queues, or anything you would naturally model as tables, SQLite is the right tool.

Choosing a Capacitor SQLite Plugin

There are two actively maintained options:

@capacitor-community/sqlite: The community plugin. Free, open source, and around for years with wide adoption. On the web platform, it stores data in IndexedDB via jeep-sqlite.
@capawesome-team/capacitor-sqlite: The plugin from the Capawesome team. It supports Android, iOS, Web, and Electron with built-in encryption (SQLCipher), transactions, versioned schema migrations, full-text search with FTS5, and first-class ORM support for Drizzle, Kysely, and TypeORM. On the web, it uses the official SQLite WASM build instead of IndexedDB, and on Electron it uses the native node:sqlite module. It is part of the sponsorware-funded Capawesome Insiders program.

Both are solid choices. The community plugin is the way to go if you need a free solution. The Capawesome plugin focuses on a smaller, simpler API, prepared statements to prevent SQL injection by design, official SQLite builds on every platform, and commercial support. The rest of this tutorial uses the Capawesome plugin, but the concepts — migrations, transactions, encryption, full-text search — apply to any Capacitor SQLite setup.

Installation

The plugin is distributed via the Capawesome npm registry, so configure it first:

npm config set @capawesome-team:registry https://npm.registry.capawesome.io
npm config set //npm.registry.capawesome.io/:_authToken

Then install the plugin and sync your native projects:

npm install @capawesome-team/capacitor-sqlite @sqlite.org/sqlite-wasm
npx cap sync

The @sqlite.org/sqlite-wasm package is only needed if you want to support the web platform.

By the way, if you are using an AI coding agent like Claude Code or Cursor, you can install the plugin with the Capawesome agent skill instead and let the agent handle the setup:

npx skills add capawesome-team/skills --skill capacitor-plugins

Platform Setup

Android

The plugin works out of the box on Android. Two optional features are worth knowing about:

Encryption: To use SQLCipher-based encryption, enable it in your variables.gradle:

ext {
  capawesomeCapacitorSqliteIncludeSqlcipher = true // Default: false
}

Bundled SQLite: Android ships with the system SQLite version, which varies by OS version and can be years old. If you need a recent SQLite version (for example for the latest FTS5 improvements), you can opt in to a bundled build:

ext {
  capawesomeCapacitorSqliteIncludeRequery = true // Default: false
}

This requires the JitPack repository in your root build.gradle:

repositories {
  google()
  mavenCentral()
  maven { url 'https://jitpack.io' }
}

iOS

No additional setup is required on iOS. The plugin supports both CocoaPods and Swift Package Manager.

Web

On the web, the plugin runs SQLite as WebAssembly using the official @sqlite.org/sqlite-wasm build, with data persisted in the Origin Private File System. Two things are required:

Serve the WASM assets. With Angular, add them to your angular.json; with Vite, exclude the package from dependency optimization:

// vite.config.ts
import { defineConfig } from 'vite';

export default defineConfig({
  optimizeDeps: {
    exclude: ['@sqlite.org/sqlite-wasm'],
  },
  server: {
    headers: {
      'Cross-Origin-Embedder-Policy': 'require-corp',
      'Cross-Origin-Opener-Policy': 'same-origin',
    },
  },
});

Set the COOP/COEP headers. SQLite WASM uses SharedArrayBuffer for persistent storage, and browsers only enable it in a cross-origin-isolated context. Your server (dev and production) must send:

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin

If persistence does not work in the browser, these headers are the first thing to check.

Then initialize the WASM module once at app startup, before opening a database:

import { Capacitor } from '@capacitor/core';
import { Sqlite } from '@capawesome-team/capacitor-sqlite';

const initialize = async () => {
  if (Capacitor.getPlatform() === 'web') {
    await Sqlite.initialize({
      worker: new Worker('/assets/sqlite-wasm/sqlite3-worker1.mjs', { type: 'module' }),
    });
  }
};

Electron

On Electron, the plugin uses the native node:sqlite module — no WASM, no third-party binaries. Databases are stored in the app's userData directory by default:

Windows: %APPDATA%\YourAppName\
macOS: ~/Library/Application Support/YourAppName/
Linux: ~/.config/YourAppName/

You can also open databases in subfolders or from absolute paths.

Opening a Database with Schema Migrations

Schema migrations are one of the most tedious parts of working with SQLite — and one of the easiest to get wrong. The plugin solves this with versioned upgrade statements that you declare right when you open the database:

import { Sqlite } from '@capawesome-team/capacitor-sqlite';

const { databaseId } = await Sqlite.open({
  path: 'mydb.sqlite3',
  version: 2,
  upgradeStatements: [
    {
      version: 1,
      statements: [
        'CREATE TABLE IF NOT EXISTS users (id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT, age INTEGER)',
      ],
    },
    {
      version: 2,
      statements: ['ALTER TABLE users ADD COLUMN email TEXT'],
    },
  ],
});

The plugin tracks the database version and applies exactly the migrations the device is missing. A fresh install runs both statements; an app updating from version 1 only runs the ALTER TABLE. No hand-rolled migration bookkeeping, no "did this user already get the new column?" bugs.

A few more options worth knowing:

// In-memory database — perfect for tests or temporary data
const { databaseId } = await Sqlite.open();

// Read-only mode — prevents accidental writes, e.g. for shipped reference data
const { databaseId } = await Sqlite.open({
  path: 'catalog.sqlite3',
  readOnly: true,
});

Opening an existing database file also just works — useful if you ship a pre-populated database with your app or import one from a backup.

Running Queries

Writes go through execute, reads through query. Both use prepared statements with bound values, which protects you from SQL injection by design — never concatenate user input into SQL strings:

await Sqlite.execute({
  databaseId,
  statement: 'INSERT INTO users (name, age) VALUES (?, ?)',
  values: ['Alice', 30],
});

const result = await Sqlite.query({
  databaseId,
  statement: 'SELECT * FROM users WHERE age > ?',
  values: [25],
});
console.log(result.columns); // ['id', 'name', 'age', 'email']
console.log(result.rows);    // [[1, 'Alice', 30, null]]

All SQLite data types are supported: NULL, INTEGER, REAL, TEXT, and BLOB. Note that query returns rows as arrays in column order, with the column names available separately in result.columns — a compact format that avoids repeating keys for every row.

One important detail: only one SQL statement can be executed per call. Statements joined with ; will not all run. If you need to run several statements, call execute once per statement — or use a transaction, which is the better tool anyway.

Transactions

When multiple writes belong together, wrap them in a transaction so they either all succeed or all roll back:

await Sqlite.beginTransaction({ databaseId });
try {
  await Sqlite.execute({
    databaseId,
    statement: 'INSERT INTO users (name, age) VALUES (?, ?)',
    values: ['Alice', 30],
  });
  await Sqlite.execute({
    databaseId,
    statement: 'INSERT INTO users (name, age) VALUES (?, ?)',
    values: ['Bob', 25],
  });
  await Sqlite.commitTransaction({ databaseId });
} catch (error) {
  await Sqlite.rollbackTransaction({ databaseId });
  throw error;
}

Transactions are not just about atomicity — they are also a massive performance win. Inserting 1,000 rows one execute at a time forces SQLite to commit to disk 1,000 times. Wrapped in a single transaction, it commits once. If you are bulk-importing data (for example during an initial sync), always batch the writes in a transaction.

Full-Text Search with FTS5

SQLite ships with a powerful full-text search engine, FTS5, and the plugin supports it out of the box. Create a virtual table, index your content, and search with MATCH:

await Sqlite.execute({
  databaseId,
  statement: 'CREATE VIRTUAL TABLE IF NOT EXISTS notes_fts USING fts5(title, body)',
});

await Sqlite.execute({
  databaseId,
  statement: 'INSERT INTO notes_fts (title, body) VALUES (?, ?)',
  values: ['Meeting notes', 'Discussed the Capacitor SQLite migration plan'],
});

const result = await Sqlite.query({
  databaseId,
  statement: 'SELECT title FROM notes_fts WHERE notes_fts MATCH ? ORDER BY rank',
  values: ['sqlite'],
});

This gives you ranked, tokenized search across thousands of records in milliseconds — entirely offline. For most apps, this removes the need for a separate search library.

Key-Value Store Included

Sometimes you still need simple key-value storage alongside your relational data — and it feels wrong to pull in a second storage plugin just for that. The plugin ships with a SqliteKeyValueStore helper that stores key-value pairs in your SQLite database:

import { Sqlite, SqliteKeyValueStore } from '@capawesome-team/capacitor-sqlite';

const store = new SqliteKeyValueStore(Sqlite);

await store.set({
  key: 'settings',
  value: JSON.stringify({ theme: 'dark', notifications: true }),
});

const result = await store.get({ key: 'settings' });
if (result.value) {
  const settings = JSON.parse(result.value);
  console.log(settings.theme); // 'dark'
}

await store.remove({ key: 'settings' });

Since it lives in the same database file, your key-value data benefits from the same encryption and is included when you back up or export the database.

Encrypting the Database

Mobile devices get lost and stolen, so encrypting data at rest matters — especially if your app stores personal or business data. The plugin supports 256-bit AES encryption via SQLCipher. You just pass an encryption key when opening the database:

const { databaseId } = await Sqlite.open({
  path: 'mydb.sqlite3',
  encryptionKey: 'secret',
});

You can rotate the key later without recreating the database:

const { databaseId } = await Sqlite.open({
  encryptionKey: 'old-secret',
});
await Sqlite.changeEncryptionKey({
  databaseId,
  encryptionKey: 'new-secret',
});

Two important rules:

Never hardcode the key. Generate it per device and store it in secure storage — for example the Capacitor Secure Preferences plugin, which uses the Android Keystore and iOS Keychain — and load it at runtime.
Remember the platform limits. Encryption is supported on Android and iOS. On Electron, database encryption is not available since node:sqlite does not support SQLCipher.

Using ORMs: Drizzle, Kysely, and TypeORM

Raw SQL is fine for small apps, but as your schema grows you may want type-safe, autocompleted queries. The plugin works with the most popular TypeScript ORMs and query builders, and there are dedicated step-by-step guides for each:

With Drizzle or Kysely, your queries are checked at compile time against your schema — a typo in a column name becomes a TypeScript error instead of a runtime crash on a user's device.

Error Handling

SQLite errors carry a result code that tells you exactly what went wrong. The plugin exposes it on the error object, so you can react to specific failures programmatically:

try {
  await Sqlite.open({ path: '/invalid/path/to.db' });
} catch (error) {
  // `error.data.sqliteCode` contains the SQLite result code
  // (e.g. `14` for `SQLITE_CANTOPEN`)
  console.error(error.message, error.data?.sqliteCode);
}

This is more robust than parsing error message strings, which can change between versions and platforms.

Performance Tips

A few practices that make a noticeable difference in real apps:

Batch writes in transactions. As mentioned above, this is the single biggest performance lever for bulk inserts.
Create indexes for your query patterns. If you frequently filter by a column (WHERE user_id = ?), add an index: CREATE INDEX idx_todos_user_id ON todos (user_id). Do this in a migration.
Run vacuum occasionally. SQLite does not automatically shrink the database file after large deletes. await Sqlite.vacuum({ databaseId }) reclaims the space — a good candidate for a maintenance task on app startup.
Close databases you no longer need. await Sqlite.close({ databaseId }) frees the underlying resources.
Use in-memory databases in tests. Opening without a path gives you a throwaway database with zero filesystem overhead.

Platform Limitations to Know

Every cross-platform abstraction has edges. These are the ones to keep in mind:

Web: Requires the COOP/COEP headers described above for persistent storage; without them, SharedArrayBuffer is unavailable.
Electron: No database encryption, and Node.js 22.5.0 or later (Electron 33+) is required for the native node:sqlite module.
All platforms: One SQL statement per execute/query call.

The plugin documentation keeps an up-to-date list of limitations and troubleshooting tips.

SQLite, Secure Preferences, or Vault?

A question that comes up a lot: when should data go into SQLite versus an encrypted key-value store? A simple decision guide:

Need queries, relations, or large datasets? → SQLite. An offline-first app that syncs structured records, or anything you would model with a server-side database.
Need encrypted key-value storage the app can read freely in the background? → Secure Preferences. Typical examples: OAuth refresh tokens, server-issued API keys.
Need encrypted storage the user must actively unlock with biometrics or a passcode? → Vault. Think password manager entries or TOTP secrets behind an "app lock" screen.

These are complementary, not competing — a common setup is SQLite for the app data, with the SQLite encryption key itself stored in Secure Preferences.

Conclusion

SQLite turns a Capacitor app into a real offline-first application: structured data, fast queries, atomic transactions, full-text search, and encryption at rest — on Android, iOS, Web, and Electron alike. With versioned upgrade statements, even schema migrations become a one-time declaration instead of an ongoing chore.

To go deeper, check out the Capacitor SQLite plugin documentation for the full API reference, platform-specific configuration, and troubleshooting guides.

Have questions or feedback? Drop a comment below — we would love to hear how you are using SQLite in your Capacitor apps.

How to Use Custom SQLite Extensions in Capacitor

Robin — Wed, 17 Jun 2026 15:06:00 +0000

SQLite ships with a lot out of the box, but sometimes you need behavior it doesn't provide: a custom FTS5 tokenizer for a language it doesn't handle well, a domain-specific SQL function, or a custom collation. Loadable extensions let you add exactly that. As of version 0.3.9, the Capacitor SQLite plugin supports custom SQLite extensions on both Android and iOS — though each platform uses a different mechanism. This guide walks through both, using a custom FTS5 tokenizer as the running example.

What are custom SQLite extensions?

A SQLite extension is native code that registers new functionality with SQLite: scalar and aggregate functions, collating sequences, virtual tables, and FTS5 tokenizers. Instead of patching SQLite or waiting for a feature upstream, you compile your code and hook it into SQLite. The official SQLite docs on run-time loadable extensions cover the C API in detail.

Two common reasons to reach for one in a mobile app:

Custom FTS5 tokenizers — the built-in tokenizers don't fit every language or matching strategy. A custom tokenizer controls exactly how text is split and normalized for full-text search.
Custom SQL functions — push logic that's awkward in SQL (specialized string processing, scoring, geospatial math) down into the database, where it runs close to the data.

Why does each platform work differently?

On Android, the system SQLite is compiled without loadable-extension support, so the plugin loads extensions into the bundled requery backend at runtime. On iOS, App Store apps can't load dynamic libraries at runtime and the system SQLite is also built without that support, so the extension has to be statically linked into the binary and registered at startup. Web isn't supported.

The upshot: the extension's C source is the same on both platforms. What changes is how you build and wire it up.

Writing a loadable extension

Every extension follows the same skeleton. The source includes sqlite3ext.h, declares the extension API with SQLITE_EXTENSION_INIT1, and exposes a single init function:

#include 
SQLITE_EXTENSION_INIT1

int sqlite3_sqlitetokenizerar_init(
  sqlite3 *db,
  char **pzErrMsg,
  const sqlite3_api_routines *pApi
) {
  SQLITE_EXTENSION_INIT2(pApi);
  /* Register your custom FTS5 tokenizer with the fts5_api here. */
  return SQLITE_OK;
}

Inside the init function you fetch the fts5_api pointer and call xCreateTokenizer with your tokenizer's callbacks. Implementing the tokenizer itself is beyond this post, but the FTS5 custom tokenizer docs describe the interface.

The init function name follows the SQLite convention sqlite3__init. The INIT1/INIT2 macros let the same source compile two ways: as a runtime-loadable extension on Android, or — with -DSQLITE_CORE — as a statically linked extension on iOS.

Loading the extension on Android

On Android, you compile the extension into a native library per CPU architecture, bundle it, and load it through the androidExtensions option.

Enable the bundled SQLite backend

Extension loading requires the requery backend. Set capawesomeCapacitorSqliteIncludeRequery to true in your app's variables.gradle:

ext {
+  capawesomeCapacitorSqliteIncludeRequery = true // Default: false
}

The requery library is published on JitPack, so add the repository to your app's build.gradle:

repositories {
    google()
    mavenCentral()
+   maven { url 'https://jitpack.io' }
}

This option can't be combined with capawesomeCapacitorSqliteIncludeSqlcipher — SQLCipher bundles its own SQLite version.

Compile for each Android ABI

A native library is compiled separately for each ABI: arm64-v8a, armeabi-v7a, x86, and x86_64. The Android NDK includes a Clang toolchain for each. Point variables at your NDK and host toolchain:

export NDK=$HOME/Library/Android/sdk/ndk/
export TOOLCHAIN=$NDK/toolchains/llvm/prebuilt/darwin-x86_64
export API=24

Set API to your minSdkVersion, then compile once per ABI:

for TARGET in \
  aarch64-linux-android:arm64-v8a \
  armv7a-linux-androideabi:armeabi-v7a \
  i686-linux-android:x86 \
  x86_64-linux-android:x86_64
do
  TRIPLE=${TARGET%%:*}
  ABI=${TARGET##*:}
  mkdir -p jniLibs/$ABI
  $TOOLCHAIN/bin/clang \
    --target=$TRIPLE$API \
    -shared -fPIC \
    -o jniLibs/$ABI/libsqlite_tokenizer_ar.so \
    sqlite_tokenizer_ar.c
done

A runtime-loadable extension doesn't link against SQLite; the INIT1/INIT2 macros route calls through the API pointer at load time. You only need sqlite3ext.h (and sqlite3.h) on the include path — grab them from the SQLite amalgamation.

Bundle the native libraries

Place the compiled .so files under android/app/src/main/jniLibs, one subfolder per ABI:

android/app/src/main/jniLibs/
├── arm64-v8a/libsqlite_tokenizer_ar.so
├── armeabi-v7a/libsqlite_tokenizer_ar.so
├── x86/libsqlite_tokenizer_ar.so
└── x86_64/libsqlite_tokenizer_ar.so

Gradle packages these automatically. The plugin resolves each extension whether the .so was extracted to the native library directory or stored uncompressed inside the APK.

Load the extension

Pass the androidExtensions option to open(), referencing each library by name (no lib prefix, no .so suffix):

import { Sqlite } from '@capawesome-team/capacitor-sqlite';

const { databaseId } = await Sqlite.open({
  path: 'my.db',
  androidExtensions: [{ name: 'sqlite_tokenizer_ar' }],
});

SQLite derives the entry point from the file name (strip lib, drop everything after the first dot, lowercase, remove non-alphanumeric characters), so libsqlite_tokenizer_ar.so resolves to sqlite3_sqlitetokenizerar_init. If your init function uses a different name, set entryPoint explicitly.

Loading the extension on iOS

iOS has no plugin option. You compile the C source into your app, declare its entry point, and register it once at startup.

First, add the source file to your app target in Xcode and set the per-file compiler flag -DSQLITE_CORE under Build Phases › Compile Sources. Then declare the init function in your bridging header:

#include 

int sqlite3_sqlitetokenizerar_init(sqlite3 *db, char **pzErrMsg, const sqlite3_api_routines *pApi);

Finally, register the extension before any database is opened — for example in your AppDelegate:

func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -&gt; Bool {
  sqlite3_auto_extension(unsafeBitCast(sqlite3_sqlitetokenizerar_init, to: (@convention(c) () -&gt; Void).self))
  return true
}

Because registration is global, there's no per-database option on iOS — the tokenizer is available everywhere.

Using a custom tokenizer in full-text search

Once loaded, your tokenizer behaves like any built-in one. Reference it in the tokenize option when creating the virtual table:

await Sqlite.execute({
  databaseId,
  statement: `
    CREATE VIRTUAL TABLE IF NOT EXISTS documents
    USING fts5(title, body, tokenize = 'sqlite_tokenizer_ar');
  `,
});

Full-text queries then run through your tokenizer automatically, with the same code on both platforms:

const { rows } = await Sqlite.query({
  databaseId,
  statement: `SELECT title FROM documents WHERE documents MATCH ?;`,
  values: ['مرحبا'],
});

Wrapping up

Custom SQLite extensions give you an escape hatch when the built-in feature set isn't enough. With the Capacitor SQLite plugin, you write the extension once and integrate it per platform: bundle a native library and pass androidExtensions on Android, or statically link and register with sqlite3_auto_extension on iOS.

The full guide is on the Capawesome blog. Have you used custom SQLite extensions in a Capacitor app? Let me know in the comments.

Cordova Live Updates: A Complete Guide to OTA Updates

Robin — Tue, 09 Jun 2026 13:00:10 +0000

For most Cordova apps, the day-to-day changes — a copy fix, a styling tweak, a JavaScript bug — live entirely in the web assets. Yet shipping one traditionally means rebuilding the native binary, resubmitting to the App Store and Google Play, and waiting out review before anyone sees it.

Live updates remove that round trip. You publish a new web bundle, and devices download and apply it on their next launch — usually within minutes, with no store submission in the loop. This guide walks through how that works in a Cordova app, the decisions that shape your setup, and a working example you can clone today.

> This post is also available on the Capawesome blog. I work on Capawesome, which builds the Cordova Live Update plugin discussed below — it's open source.

What is a live update?

A Cordova app has two layers. The native layer is the compiled binary from the store — the WebView, the plugins, the platform glue. The web layer is everything inside that WebView: your HTML, CSS, JavaScript, and assets.

A live update is an over-the-air (OTA) update of the web layer only. The native binary stays untouched. Because nothing native changes, you don't need an app review and users don't have to do anything.

The one rule that matters: you can only update what already exists in the native binary. A copy change, a CSS tweak, a web framework upgrade — all fine. Adding or upgrading a Cordova plugin, or anything touching native code, AndroidManifest.xml, or Info.plist — that still needs a real store release.

A nice detail: it works with the stock WebView

If you're coming from Ionic Appflow, here's a welcome difference. The Cordova Live Update plugin works with the stock Cordova WebView. It does not require cordova-plugin-ionic-webview.

It hooks into Cordova's official scheme handlers — https://localhost/ on Android via WebViewAssetLoader, app://localhost/ on iOS via WKURLSchemeHandler. The only thing to avoid is forcing the legacy file scheme (AndroidInsecureFileModeEnabled set to true, or Scheme set to file), which bypasses the handlers the plugin relies on.

Setup

Create an app in Capawesome Cloud:

npx @capawesome/cli apps:create --type cordova

Install the plugin with the app ID it returns:

cordova plugin add @capawesome/cordova-live-update --variable APP_ID=00000000-0000-0000-0000-000000000000

Configure the rest through config.xml preferences:

Picking an update strategy

The AUTO_UPDATE_STRATEGY preference has two values, background and none. Around them you can build four patterns.

Background is the simplest — zero app-side code. The plugin checks on app start and resume, downloads in the background, and applies on the next cold start. There's a built-in 15-minute minimum between checks so it can't turn into a battery-draining poll loop.

Always Latest (recommended) keeps the background download but prompts the user to apply as soon as the bundle is staged. You opt in with the nextBundleSet event:

document.addEventListener("deviceready", () =&gt; {
  cordova.plugins.LiveUpdate.addListener("nextBundleSet", async ({ bundleId }) =&gt; {
    if (!bundleId) {
      return;
    }
    const shouldReload = confirm("A new version is available. Install it now?");
    if (shouldReload) {
      await cordova.plugins.LiveUpdate.reload();
    }
  });
});

The download already happened in the background, so there's no network wait when the user taps "install".

Force Update blocks app start until the latest bundle is applied — reserve it for cases where stale code is genuinely unsafe. Instant uses a silent push notification to tell the app to check right now; it's a break-glass tool for live incidents, not an everyday flow.

Matching bundles to native versions

The most common production failure with live updates is shipping a web bundle that doesn't match the installed binary — for example, a bundle that calls a plugin method only added in a later native version. If it reaches an older binary, the app breaks on launch.

You prevent it by binding bundles to native versions. The cleanest pattern is one channel per native version: read the version code at runtime and pass the channel directly to sync():

const { versionCode } = await cordova.plugins.LiveUpdate.getVersionCode();
await cordova.plugins.LiveUpdate.sync({ channel: `production-${versionCode}` });

Every deployment is then addressed to a specific native version by name, so a bundle can't land on a binary that can't run it. For a single-channel setup, you can also just set DEFAULT_CHANNEL in config.xml.

Automatic rollbacks

This is the single most important safety net. Two preferences do the work:

If your app doesn't call ready() within READY_TIMEOUT milliseconds of starting, the plugin assumes the new bundle is broken and reverts on the next launch. AUTO_BLOCK_ROLLED_BACK_BUNDLES stops that bundle from ever being re-downloaded (it has no effect unless READY_TIMEOUT is greater than 0).

On the app side, call ready() as early as you can — right after deviceready:

document.addEventListener("deviceready", async () =&gt; {
  await cordova.plugins.LiveUpdate.ready();
});

As soon as your bootstrap code runs without crashing, call ready(). The whole mechanism only works if you do.

Code signing

Whatever code you ship runs in your app's context, so a tampered bundle means code execution inside your app. Code signing adds authenticity and integrity on top of HTTPS with a standard RSA keypair.

Generate the keypair, sign uploads with the private key, and add the public key to config.xml:

npx @capawesome/cli apps:liveupdates:generatesigningkey
npx @capawesome/cli apps:liveupdates:upload --private-key private.pem

From there, the app verifies every downloaded bundle and refuses anything that isn't signed by your key. Worth enabling in production, especially with multiple channels or self-hosting.

Shipping an update

Once it's wired up, a release is two commands:

npm run build
npx @capawesome/cli apps:liveupdates:upload --channel production

Devices on that channel pick it up on their next launch, download it in the background, and prompt the user to apply it. You can also roll out gradually — --rollout-percentage 10 reaches 10% of the channel, and you widen it once the dashboards look clean.

Try it

The official Cordova Live Update Demo app is a small, dependency-free Cordova app that shows the plugin downloading and applying an OTA bundle on a real device. Clone it, point it at your own Capawesome Cloud app, and watch an update land before wiring up anything in your own codebase.

If you're migrating off Appflow, the concepts map closely — channels stay channels, and the background/none strategies have direct equivalents. The full guide, including the migration path, is on the Capawesome blog.

Questions or feedback? I'd genuinely like to hear how your Cordova OTA setup goes — drop a comment.

Announcing Cordova Support in Capawesome Cloud

Robin — Mon, 08 Jun 2026 13:15:01 +0000

Capawesome Cloud now officially supports Apache Cordova. That means out-of-the-box native iOS and Android builds, automated App Store submissions, and — the part we're most excited about — over-the-air Live Updates through our brand new Cordova Live Update plugin.

With Ionic Appflow winding down (it stopped selling to new customers in February 2025 and reaches full end-of-life on December 31, 2027), Cordova teams have been left without a real option for cloud builds and live updates. Consider this their new home.

Why Cordova, Why Now

Most modern build and update services target Capacitor or React Native and treat Cordova as an afterthought, if they support it at all. But Cordova hasn't gone anywhere — it's still actively maintained by The Apache Software Foundation, and a large number of teams continue to ship and grow production Cordova apps. Those teams deserve the same first-class tooling everyone else gets.

Native Builds Without the Config

Building a Cordova app for iOS and Android usually means maintaining your own macOS runners and babysitting YAML pipelines. Capawesome Cloud removes all of that — you connect your Git repository, and we build it. No build configuration files, no CI service to wire up, no Mac required.

The Headline: Live Updates for Cordova

Native builds and publishing matter, but live updates are why most teams came to Appflow in the first place. Pushing a JavaScript, HTML, or CSS fix over the air — and having it on every device in minutes instead of waiting days for app review — is hard to give up once you've had it.

One detail Cordova developers will appreciate: the 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.

Installation is a single command, with your Capawesome Cloud app ID passed as a variable:

cordova plugin add @capawesome/cordova-live-update --variable APP_ID=00000000-0000-0000-0000-000000000000

You configure the plugin through preferences in your config.xml. The background strategy checks for updates on launch and resume, downloads them silently, and applies them on the next start:

For rollback to work, your app needs to confirm it started successfully. Call ready() as early as possible once Cordova is initialized:

document.addEventListener("deviceready", async () =&gt; {
  await cordova.plugins.LiveUpdate.ready();
});

Shipping an update is then just a matter of building your web assets and uploading them as a bundle:

npm run build
npx @capawesome/cli apps:liveupdates:upload --channel production

See It Without Signing Up

Want to see Live Updates in action before wiring anything up yourself? We maintain an official Cordova Live Update Demo app that shows the plugin downloading and applying an over-the-air bundle on a real device. There's nothing to sign up for and nothing to deploy — clone the repo, build the app, and watch a live update land.

A Drop-In Replacement for Appflow

If you're coming from Appflow, the move is meant to be painless. Appflow's app ID becomes your Capawesome Cloud app ID, channels stay channels, and the update methods have direct equivalents. You swap cordova-plugin-ionic for @capawesome/cordova-live-update, point it at Capawesome Cloud, and keep shipping.

Get Started

Cordova support is live right now, and the free tier is enough to ship your first live update. Read the full announcement on our blog, and let us know what you're building.

Announcing the Capacitor Vault Plugin: Secrets Behind a Biometric Lock

Robin — Mon, 01 Jun 2026 14:00:15 +0000

Storing secrets on a mobile device sounds simple until you try to do it properly. You want them encrypted at rest, gated behind the user's biometrics or passcode, and you want that unlock to cover a whole session rather than firing a prompt on every read. That's exactly the gap the new Capacitor Vault plugin fills.

In this post, we'll look at why it exists, what it does, and how to use it.

Why Another Storage Plugin?

We already ship two related plugins:

Secure Preferences — encrypted key/value storage the app reads freely in the background.
Biometrics — on-demand biometric prompts.

Neither covers the "active lock + session" pattern. Secure Preferences is silent: there's no user-facing gate. Biometrics gives you a single prompt, but no notion of a session that stays unlocked across many reads and writes.

That session pattern is the one Ionic Identity Vault popularized — and it's being discontinued. The Capacitor Vault plugin fills that gap with a drop-in alternative, and adds first-class multi-vault support along the way.

What You Get

Active lock state — a single biometric or passcode prompt unlocks the vault, so you can read and write many values before it locks again.
Three vault types — Biometric, BiometricOrDevicePasscode, and DevicePasscode.
Auto-lock on background — configure how long the app can be backgrounded before the vault locks itself.
Lock and unlock events — with a trigger reason (MANUAL or TIMEOUT).
Multi-vault — independent vaults with their own keys and lock policies.
Hardware-backed encryption — keys live in the Android Keystore and iOS Keychain, with AES-256-GCM as the data cipher.
Key invalidation — a typed KEY_INVALIDATED error when the device's biometric set changes.
Export and import — a built-in migration API.
Typed error codes — branch on conditions like UNLOCK_CANCELED or BIOMETRY_NOT_AVAILABLE.

The plugin supports Capacitor 8 and above. A localStorage-backed web implementation is included for cross-platform development, but is clearly marked unsafe for production.

A Quick Tour

Initialize the Vault

Before anything else, initialize the vault once per session:

import { Vault, VaultType } from '@capawesome-team/capacitor-vault';

await Vault.initialize({
  type: VaultType.Biometric,
  title: 'Unlock vault',
  cancelButtonText: 'Cancel',
  iosFallbackButtonText: 'Use Passcode',
  lockAfterBackgrounded: 30000, // Use 0 to lock immediately on background
});

Unlock the Vault

Calling unlock() triggers the platform's authentication prompt, and typed errors tell you exactly what happened:

import { Vault, ErrorCode } from '@capawesome-team/capacitor-vault';

try {
  await Vault.unlock();
} catch (error) {
  if (error.code === ErrorCode.UnlockCanceled) {
    // User dismissed the prompt
  } else if (error.code === ErrorCode.KeyInvalidated) {
    // Biometric set changed — re-enrollment required
  } else {
    throw error;
  }
}

Read and Write Values

While the vault is unlocked, reads and writes behave like any key/value store:

import { Vault } from '@capawesome-team/capacitor-vault';

await Vault.setValue({ key: 'session_token', value: 'eyJhbGciOiJIUzI1NiIs...' });
const { value } = await Vault.getValue({ key: 'session_token' });

Lock and Listen for Events

Lock manually with lock(), and subscribe to events to keep your UI in sync:

import { Vault } from '@capawesome-team/capacitor-vault';

await Vault.addListener('lock', ({ vaultId, trigger }) => {
  console.log(`Vault ${vaultId} locked (trigger: ${trigger}).`);
});
await Vault.addListener('unlock', ({ vaultId }) => {
  console.log(`Vault ${vaultId} unlocked.`);
});

Multiple Vaults

Every method accepts an optional vaultId. Pass different identifiers and you get fully independent vaults — separate keys, separate lock state, separate prompts:

import { Vault, VaultType } from '@capawesome-team/capacitor-vault';

await Vault.initialize({ vaultId: 'alice', type: VaultType.Biometric, title: "Unlock Alice's vault" });
await Vault.initialize({ vaultId: 'bob', type: VaultType.BiometricOrDevicePasscode, title: "Unlock Bob's vault", lockAfterBackgrounded: 60000 });

This is handy for multi-account apps, where each user's secrets live behind their own lock.

Vault, Secure Preferences, or SQLite?

The right choice depends on how the data is accessed:

SQLite — relational data with queries, joins, and indexes.
Secure Preferences — encrypted key/value the app reads freely in the background (OAuth refresh tokens, API keys).
Vault — encrypted key/value the user must actively unlock with biometrics or a passcode (password manager entries, TOTP secrets, app-lock screens).

Migrating from Ionic Identity Vault

If you're moving off Ionic Identity Vault, the exportData(...) and importData(...) methods give you a one-shot migration path.

Try It Out

The Capacitor Vault plugin is available now to all Capawesome Insiders. There's also an open-source demo app that walks through the full flow.

This article was originally published on the Capawesome blog. If you have questions or feedback, join us on Discord or subscribe to the newsletter.

Capacitor Edge-to-Edge & Safe Areas: The Complete Guide

Robin — Fri, 29 May 2026 17:41:18 +0000

Edge-to-edge has been one of the rougher edges of building with Capacitor for the past two years. Status bars hiding the top of your header, navigation gestures obscuring buttons, an Android plugin patched into every project just to make insets work — most teams ended up with a workaround instead of a real solution.

That story changed quietly between Capacitor 8.3.0 and 8.3.2. The framework now ships proper edge-to-edge support out of the box on both platforms, and the third-party plugin most projects relied on has moved from "recommended" to "fallback for special cases." This guide is the up-to-date playbook: what the platforms expect, what Capacitor finally fixed, and the small set of CSS you actually need to write today.

What Edge-to-Edge Means, and Why It Matters Now

Edge-to-edge is the design pattern where your app's content extends all the way under the system bars — the status bar at the top, the navigation bar at the bottom, the gesture indicator on iOS. The bars are still visible, but they sit on top of your content instead of pushing it down. The visible result is a fuller, more immersive screen. The technical result is that you are now responsible for making sure nothing important — a header title, a logout button, a floating action button — ends up trapped under one of those bars.

On iOS, this has been the default since the iPhone X in 2017. The platform exposes the env(safe-area-inset-*) CSS variables for content that should stay clear of notches, the home indicator, and the status bar. Most Capacitor projects already handle this.

Android is the part that recently changed. Starting with Android 15 (API level 35), edge-to-edge is enforced for any app targeting SDK 35 or later — and once your Play Store listing requires SDK 35, every install on Android 15+ gets the new behavior. On Android 16, the previous opt-out via windowOptOutEdgeToEdgeEnforcement is gone entirely. There's no escape hatch left.

For Capacitor apps the consequence is unavoidable: your WebView now renders behind the status and navigation bars on modern Android, and your CSS needs to account for that. The good news is that, as of Capacitor 8.3.2, the framework gives you the information you need to do it cleanly.

The Old Pain Points

To appreciate what 8.3.x fixed, it helps to remember what shipping edge-to-edge with Capacitor used to look like.

The StatusBar plugin's escape hatches stopped working. For years, the common workaround was to set overlaysWebView: false and backgroundColor on the @capacitor/status-bar plugin and call it a day — the WebView would simply not extend under the status bar. That approach quietly stopped working on Android 16, because both options depend on Android's opt-out behavior, which Android 16 no longer allows.

The CSS variables returned the wrong values. Even when you tried to do things the "right way" with env(safe-area-inset-top) and friends, Android WebView versions below 140 had a bug that returned incorrect values. Your top inset would sometimes be 0, sometimes off by a few pixels — almost never right.

The de-facto workaround was a plugin. Most projects ended up installing the Android Edge-to-Edge Support plugin, which sidestepped the broken CSS variables by applying insets to the WebView itself. It worked, but it meant carrying a non-trivial third-party dependency that wouldn't be needed once the platform caught up.

The platform has now caught up.

What Capacitor 8.3.0 – 8.3.2 Fixed

Three releases over roughly six weeks closed the gap:

8.3.0 — SystemBars now uses native safe area insets on Android. This is the foundational change. The framework reads insets from WindowInsetsCompat and injects them as parallel --safe-area-inset-* CSS custom properties. That matters because Android WebView versions below 140 still have a bug where env(safe-area-inset-*) returns the wrong values — the injected variables sidestep the bug entirely, and the recommended pattern is to combine both with a var() fallback.
8.3.1 — Separate style state for the status bar and navigation bar, so styling one no longer accidentally affects the other.
8.3.2 — Removed extra view padding on Android API levels ≤ 34, which had been pushing content down by an unwanted amount on older devices.

Together, these mean that on a project running Capacitor 8.3.2 or later, a single CSS rule per edge — the injected --safe-area-inset-* variable with env() as a fallback — gets you correct safe area handling on both iOS and Android, all the way down to the WebViews that still ship the env() bug. No third-party plugin, no manual JavaScript, no platform branching.

The Recommended 2026 Setup

Three core pieces, plus a couple of optional polish steps.

1. Upgrade to Capacitor 8.3.2 or Later

This is the whole prerequisite. If you're on 8.3.2+, you can skip the rest of this section. If you're on an older 8.x or on 7.x, bump it now — the upgrade is small and the payoff is large.

npm install @capacitor/core@^8.3.2 @capacitor/cli@^8.3.2
npm install @capacitor/android@^8.3.2 @capacitor/ios@^8.3.2
npx cap sync

2. Set the Viewport Meta Tag

Both platforms require an opt-in for the WebView to extend under safe areas. Add viewport-fit=cover to your viewport meta tag in index.html:

Without this, iOS will respect the safe areas automatically by not drawing under the notch — which is sometimes what you want, but it isn't edge-to-edge. If your goal is a full-bleed UI, the viewport-fit=cover opt-in is mandatory.

3. Use the Safe-Area CSS Variables

The web platform exposes safe-area insets via the env(safe-area-inset-*) function — four values for top, right, bottom, and left. iOS and Android WebView 140+ return correct values here; older Android WebViews don't, which is exactly why Capacitor also injects parallel --safe-area-inset-* custom properties.

The recommended pattern is to read the injected variable first and fall back to env():

.app-header {
  padding-top: var(--safe-area-inset-top, env(safe-area-inset-top, 0px));
}

.app-footer {
  padding-bottom: var(
    --safe-area-inset-bottom,
    env(safe-area-inset-bottom, 0px)
  );
}

.app-content {
  padding-left: var(--safe-area-inset-left, env(safe-area-inset-left, 0px));
  padding-right: var(--safe-area-inset-right, env(safe-area-inset-right, 0px));
}

The trailing 0px keeps things sensible on environments where neither value is defined — desktop previews, older browsers, and the like.

If you want to combine the inset with an existing padding value, wrap the whole thing in a calc():

.app-header {
  padding-top: calc(
    var(--safe-area-inset-top, env(safe-area-inset-top, 0px)) + 1rem
  );
}

That's the whole core of safe area handling. Everything below this is platform-specific polish.

4. Configure SystemBars (Optional)

Capacitor's built-in SystemBars API (part of @capacitor/core, no extra install) controls the styling and visibility of the system bars. The default insetsHandling: "css" is what makes the CSS variables work — leave it on.

The most common configuration is just choosing a style:

import type { CapacitorConfig } from "@capacitor/cli";

const config: CapacitorConfig = {
  plugins: {
    SystemBars: {
      style: "DARK",
    },
  },
};

export default config;

DARK makes the icons in the status and navigation bars dark — appropriate for a light app background. LIGHT does the opposite, for a dark app. DEFAULT follows the system theme.

If you need to change the style at runtime, the API exposes setStyle() per bar:

import { SystemBars, SystemBarsStyle, SystemBarType } from "@capacitor/core";

await SystemBars.setStyle({
  bar: SystemBarType.StatusBar,
  style: SystemBarsStyle.Light,
});

Note that the modern SystemBars API does not include setOverlaysWebView() or setBackgroundColor(). Those still exist on the legacy @capacitor/status-bar plugin for backward compatibility, but as covered earlier, they're no-ops on Android 16+. If you need a colored status bar background, the recommended approach is now an HTML element with your background color and the safe-area padding applied.

There's one related gap on Android worth knowing about: coloring the navigation bar background. In edge-to-edge mode the gesture navigation bar is transparent, so your content shows through and there's nothing to color. But devices still using the older three-button navigation render an opaque bar — and SystemBars can only set its style (dark or light icons), not its background color. To color the Android navigation bar background, the @capawesome/capacitor-navigation-bar plugin exposes a setColor(...) method:

import { NavigationBar } from "@capawesome/capacitor-navigation-bar";

await NavigationBar.setColor({ color: "#ffffff" });

5. iOS-Specific Considerations

iOS has had safe areas for nearly a decade, so most of this works out of the box. Two settings are worth verifying.

UIViewControllerBasedStatusBarAppearance in your Info.plist controls whether each view controller can set its own status bar style or whether the value is fixed app-wide. For Capacitor apps, leave it at the default of YES so SystemBars.setStyle() works at runtime:

UIViewControllerBasedStatusBarAppearance

UIStatusBarStyle sets the initial status bar style before your JavaScript loads. Match it to your launch screen:

UIStatusBarStyle
UIStatusBarStyleDarkContent

That's all there is on iOS. The env(safe-area-inset-*) values have always been correct here, so the var() / env() pair from earlier resolves cleanly; the home indicator gap is handled automatically when you pad the bottom edge, and the WebView extends edge-to-edge as soon as viewport-fit=cover is set.

Ionic Framework Specifics

If you're on Ionic, almost every component already applies safe-area padding correctly. ion-header, ion-footer, ion-tab-bar, ion-toolbar, and ion-content all read the same env(safe-area-inset-*) values (re-exposed as --ion-safe-area-top, --ion-safe-area-bottom, etc.) and lay themselves out accordingly. You usually don't have to touch anything.

The exception that bites people is ion-fab. The framework only applies safe-area padding to a FAB when it can position itself relative to a header or footer. Drop a vertical="top" FAB onto a page without an ion-header and it sits at coordinate 0 — directly under the status bar. A few lines of CSS fix it:

ion-fab[vertical="top"] {
  margin-top: var(--ion-safe-area-top, 0);
}

ion-fab[vertical="bottom"] {
  margin-bottom: var(--ion-safe-area-bottom, 0);
}

Use the attribute selectors so the rule only applies where it's needed. The 0 fallback in var() keeps the layout sensible on platforms or devices where the variable isn't set.

Bonus: Tailwind CSS with `tailwindcss-safe-area`

If your project uses Tailwind, hand-writing padding-top: env(safe-area-inset-top) everywhere stops feeling Tailwind-ish very quickly. The community package tailwindcss-safe-area fills that gap with a clean set of utilities.

Install it (the v4 install — for Tailwind v3, see the package README):

npm install tailwindcss-safe-area

Then import it in your main CSS file alongside Tailwind:

@import "tailwindcss";
@import "tailwindcss-safe-area";

Make sure your viewport meta tag still has viewport-fit=cover — the utilities rely on env() under the hood and need the WebView to be in edge-to-edge mode. One caveat: because the package uses env() directly and doesn't read the injected --safe-area-inset-* variables, users on Android WebView versions below 140 will see 0 insets. For most apps that's a rapidly shrinking minority, but if you need to cover those devices, hand-roll the var() / env() fallback on the critical elements.

The most useful classes follow the same naming pattern as Tailwind's built-in spacing:

...
...
...

Two variants make this far more flexible than plain env():

pt-safe-offset-4 applies the safe-area inset plus 1rem (Tailwind's 4 spacing token), the equivalent of calc(env(safe-area-inset-top) + 1rem).
pb-safe-or-8 applies the safe-area inset or 2rem, whichever is larger — handy when you want a minimum bottom padding on devices without a home indicator.

There are matching utilities for margins, scroll padding, borders, height (h-screen-safe, h-dvh-safe), and inset positioning (top-safe, bottom-safe). For a Tailwind-first app, this package removes nearly all hand-written safe-area CSS.

When the Capawesome Plugin Still Fits

The Android Edge-to-Edge Support plugin is still maintained and still useful — its role has just changed. With Capacitor 8.3.2+ handling insets natively, you only need the plugin if you don't want to implement safe-area handling in CSS at all. The plugin keeps the traditional Android behavior: it applies the system bar insets directly to the WebView, so your content never goes edge-to-edge in the first place and you don't have to add a single line of env(safe-area-inset-*) CSS to your app.

That tradeoff is appealing in a couple of specific situations:

Legacy apps you don't want to restyle. A long-running app with hundreds of screens, none of which were written with edge-to-edge in mind, can install the plugin and keep behaving the way it always did on Android.
Capacitor 7 or earlier. The native fix only landed in 8.3.0. If you're still on 7, the plugin is genuinely your best option until you can upgrade.
You want a colored status bar background on Android. The legacy StatusBar.setBackgroundColor() no longer works on Android 16. The plugin's setBackgroundColor(), setStatusBarColor(), and setNavigationBarColor() methods still do.

For any new project, or any project where you're willing to spend an hour adding pt-safe / env(safe-area-inset-top) to a few elements, the CSS-first approach is the cleaner long-term choice — fewer dependencies, standard CSS, and consistent behavior across iOS and Android.

Conclusion

For the last two years, "doing edge-to-edge in Capacitor" meant installing a plugin and accepting some duct tape. As of Capacitor 8.3.2, it means three lines of meta tag and CSS — the standard the web platform has had for years finally works the same way on both iOS and Android. Ionic users get most of the work for free, Tailwind users get a clean utility set with tailwindcss-safe-area, and the third-party Android plugin is now a deliberate choice for the few apps that want to opt out of edge-to-edge entirely.

Got questions or war stories from your own edge-to-edge rollout? Drop a comment below.

Capacitor Live Updates: A Complete Guide to OTA Updates

Robin — Sat, 16 May 2026 20:24:32 +0000

Shipping a fix used to mean a bundled binary, an app store review, and a few days of hoping users would tap "update". With Capacitor Live Updates that loop shrinks to minutes. You push a new web bundle, devices pick it up on the next launch, and the next version of your app is already in users' hands.

This is the long version of how that works. We'll walk through what live updates actually are, the three choices every team has to make when setting them up, the security model, the production patterns that keep you out of trouble, and a real-world end-to-end example.

Cross-posted from the Capawesome docs blog.

What Are Live Updates?

A Capacitor app has two layers. The native layer is the compiled binary installed from the App Store or Google Play — the WebView, the native plugins, and the platform glue. The web layer is everything inside that WebView: your HTML, CSS, JavaScript, and static assets.

A live update is an Over-the-Air (OTA) update of the web layer only. The native binary stays untouched. Instead of pushing a new build to the stores, you upload a new web bundle to a delivery service, and the Live Update plugin downloads it, swaps it in, and reloads.

The constraint is also the feature: because nothing native changes, you don't need an app store review and you don't need users to take any action.

Why teams use them

Hotfixes in minutes, not days. A critical bug — broken login, wrong API URL, regression in checkout — can be patched before most users notice.
Faster feature iteration. Ship small improvements as soon as they're ready instead of batching them into a monthly native release.
Staged rollouts and A/B testing. Roll a new bundle out to 5% of users, watch the dashboards, then expand.
Smaller user friction. Users don't have to manually tap "update" in the store.

Binary-Compatible vs. Non-Binary-Compatible Changes

The single most important rule: you can only update what already exists in the native binary. Changes that don't touch native code are binary-compatible. Anything else needs a real app store release.

Change	Binary-compatible?
HTML, CSS, JavaScript	Yes
Images, fonts, JSON, web-only assets	Yes
Web framework upgrade	Yes
Plugin added/removed or major version bump	No
Native code (Java/Kotlin/Swift/Objective-C)	No
`AndroidManifest.xml`, `Info.plist`, entitlements	No
App icon, splash screen	No

A useful mental model: if your change only modifies files inside your web project — your src/, your build output — and doesn't add, remove, or upgrade a Capacitor plugin or any native code or config, it's binary-compatible.

App Store Compliance

Both Apple and Google explicitly allow downloading and executing code inside a WebView. Apple's App Store Review Guidelines (3.3.2) allow interpreted code as long as it doesn't change the primary purpose of the app, doesn't create a storefront for other code, and doesn't bypass the system's signing or sandbox. Google Play carves out an explicit exception for "code that is interpreted in a virtual machine or runtime (like JavaScript in a webview or browser)."

In short: app stores draw the line at native self-modification. Live updates only touch the web layer, so they stay safely on the right side of that line.

Wiring It Up

npm install @capawesome/capacitor-live-update
npx cap sync

Create an app in Capawesome Cloud (the CLI prints the app ID):

npx @capawesome/cli apps:create

Then add the plugin to your Capacitor config:

const config: CapacitorConfig = {
  plugins: {
    LiveUpdate: {
      appId: '00000000-0000-0000-0000-000000000000',
      autoUpdateStrategy: 'background',
      autoBlockRolledBackBundles: true,
      readyTimeout: 10000
    }
  }
};

For full setup instructions, see the Live Updates setup guide.

Three Choices to Make

Decision 1: Update Strategy

The strategy decides when an update is downloaded, when it's applied, and whether the user is involved. It's as much a UX decision as a technical one.

Strategy	User-visible delay	Use case
Background	Next cold start	Silent updates between sessions
Always Latest (recommended)	One prompt after download	User informed and chooses when to apply
Force Update	Blocks app start	Apps where stale code is genuinely unsafe
Instant	Fires on push	Critical hotfixes for a live incident

Background is the simplest — set it once in your config and the plugin checks on app start, downloads in the background, and applies on the next cold start. The tradeoff is invisibility: users won't know a new version exists.

Always Latest (our recommendation) is background plus a prompt. You listen for nextBundleSet and ask the user to apply the update once it's already downloaded:

import { LiveUpdate } from '@capawesome/capacitor-live-update';

LiveUpdate.addListener('nextBundleSet', async ({ bundleId }) => {
  if (!bundleId) return;
  const shouldReload = confirm('A new version is available. Install it now?');
  if (shouldReload) {
    await LiveUpdate.reload();
  }
});

The download happens in the background, so there's no waiting on the network when the user taps "install".

Force Update keeps the splash screen visible while the app syncs at startup — guarantees freshness, costs UX on slow connections. Instant uses a silent push notification to tell devices to sync immediately — meant for critical hotfixes, not everyday flows.

Decision 2: Versioning Strategy

This is the decision that prevents the most common production failure: shipping a web bundle that doesn't match the installed native binary.

Picture a user with version 5 of your native app. You ship a new web bundle that calls a method on a plugin you only added in version 6. If that bundle reaches the v5 user, their app crashes on launch.

You prevent this by binding each web bundle to the range of native versions it's compatible with. Two approaches:

Versioned bundles — attach min/max version ranges on each upload. Simple but error-prone.
Versioned channels (recommended) — one channel per native version (e.g. production-10, production-11).

The cleanest way to wire versioned channels is at build time, in the native config:

// android/app/build.gradle
android {
    defaultConfig {
        versionCode 60003
        resValue "string", "capawesome_live_update_default_channel",
                 "production-" + defaultConfig.versionCode
    }
}


CapawesomeLiveUpdateDefaultChannel
production-$(CURRENT_PROJECT_VERSION)

Every native release ships pinned to its own channel. Bumping the native version automatically opens a new channel for compatible web bundles. No JavaScript-side state to manage.

The real win is safety. Every deployment is addressed to a specific native version by name, so it's much harder to accidentally ship a bundle to a binary that can't run it.

Decision 3: Update Delivery Method

How is the bundle packaged for transport?

Zip (recommended) — the whole web folder is compressed into one .zip. Compression typically halves the size; the download is a single HTTP request; it works regardless of how your build tool names files.
Manifest (delta) — each file is uploaded individually, and the device only downloads changed files based on hashes.

In theory delta is great. In practice, modern bundlers (Vite, Angular CLI, Webpack 5+, Nuxt) all use content-hashed filenames like chunk-3a7f2b.js. Filenames change whenever content changes, which defeats delta comparison: every file looks new, so every file gets downloaded, and you lose the single-zip compression on top.

One team we know had a 20 MB bundle on manifest and 9 MB on zip for the exact same web output. Start with zip — only consider manifest if you have specific stable-named large static assets.

Security: Code Signing

Live updates run on the same trust model as your native binary: whatever code you ship will execute in your app's context. If someone can replace a bundle in transit, they get code execution inside your app. Even though the Cloud uses HTTPS, defense in depth matters.

Code signing closes the gap with two guarantees:

Authenticity — the bundle was produced by someone holding your signing key.
Integrity — the bundle wasn't modified between upload and install.

The mechanism is a standard RSA keypair. The private key signs each bundle on upload; the public key is embedded in your app config and used to verify every downloaded bundle before it's applied.

# Generate keypair
npx @capawesome/cli apps:liveupdates:generatesigningkey

# Sign every upload
npx @capawesome/cli apps:liveupdates:upload --private-key private.pem

Paste the public key into your Capacitor config and your app will refuse to apply anything not signed by your private key. We strongly recommend enabling this in production.

Best Practices

Automatic Rollbacks

The single most important safety net. Tell the plugin to roll back to the previous bundle if the new one fails to start, and not to retry a bundle that's already failed:

{
  "plugins": {
    "LiveUpdate": {
      "readyTimeout": 10000,
      "autoBlockRolledBackBundles": true
    }
  }
}

If your app doesn't call LiveUpdate.ready() within readyTimeout milliseconds of starting, the plugin reverts to the previous bundle on the next launch. Call ready() as early as you can — in your root component's initialization, before anything else can fail.

Bundle Size Optimization

Three optimizations cover most of the wins:

Drop source maps. Often 75% of bundle size. Set build.sourcemap: false in Vite, --source-map=false in Angular. Upload to Sentry separately if needed.
Stick with zip. Unless you have evidence delta will work, zip is smaller in practice.
Move heavy static assets out of the bundle. Hero images, marketing media — host on a CDN and load on demand.

Reasonable Update Checks

Don't poll:

// Don't do this.
setInterval(() => {
  LiveUpdate.sync();
}, 60_000);

autoUpdateStrategy: 'background' already does the right thing — it checks on app start and on resume with a 15-minute minimum between checks. If you genuinely need a faster update path, use Instant with a silent push.

Gradual Rollouts

You don't have to release to 100% of users at once:

npx @capawesome/cli apps:liveupdates:upload --rollout-percentage 10

That bundle reaches 10% of devices. Watch your error tracking, your crash dashboards, and bump it up when things look good.

A Real-World Example

A real Capacitor app shipping to thousands of users — the DHBW VS app — runs the full recommended stack: Always Latest + versioned channels via native config + zip delivery + automatic rollback + code signing.

The version-sync part is handled by commit-and-tag-version (bumps package.json from conventional commits) and Capver (mirrors that version into Android and iOS). A release tagged 6.0.3 becomes Android versionCode 60003 and iOS CURRENT_PROJECT_VERSION 60003 — three two-digit groups for major/minor/patch. That deterministic mapping is what makes build-time channel pinning work without manual bookkeeping.

At startup, the root component calls ready() and registers the nextBundleSet listener:

private initializeLiveUpdate(): void {
  if (!Capacitor.isNativePlatform()) {
    return;
  }
  void LiveUpdate.ready();
  LiveUpdate.addListener('nextBundleSet', async event => {
    if (!event.bundleId) return;
    const confirmed = confirm('A new version is available. Install it now?');
    if (confirmed) {
      await LiveUpdate.reload();
    }
  });
}

The GitHub Actions workflow takes a channel name as input and runs two CLI commands: create the channel (idempotent with --ignore-errors) and build/deploy the web bundle in the cloud. To deploy a live update for native version 60003, the team triggers the workflow with production-60003 as the channel. Devices on that native version pick it up on their next launch.

Wrapping Up

Live updates are the difference between releasing fixes in minutes and releasing them in days. The recommended path is the same for almost every team:

Always Latest strategy so users are informed when an update is ready
Versioned channels configured natively so version compatibility is automatic
Zip delivery for predictable bundle sizes
Automatic rollback so a broken bundle is self-healing
Code signing when you ship to production

Everything else — rollouts, force updates, push-driven hotfixes, self-hosting — sits on top of that core.

For the full version with more depth on every section, see the original post on the Capawesome docs blog.

Questions or feedback? Drop into the Capawesome Discord or hit me up in the comments.

How to Use AI Agents in Capacitor App Development

Robin — Sat, 09 May 2026 08:47:01 +0000

AI coding agents are a great match for everyday web development, but they tend to fall apart the moment a Capacitor project crosses into native territory — Xcode toolchains, Gradle versions, signing certificates, plugin configuration, and a dozen other details that aren't well represented in their training data. In this guide, you'll learn how to set up an AI agent so it can confidently support you through the entire Capacitor app lifecycle: creating a new app, adding plugins, building, debugging, deploying, and maintaining it over time.

Why General-Purpose AI Agents Struggle with Capacitor

Capacitor sits at the intersection of web and native, and that's exactly where general-purpose AI agents tend to break down. Bumping an Android compileSdkVersion, wiring up an iOS entitlement, or migrating a project from CocoaPods to Swift Package Manager involves platform-specific steps that change with every release. Without that context, an agent often invents commands, picks an outdated configuration, or skips a critical step entirely.

To fix this, you need two things working together:

Agent skills — structured procedural knowledge that teaches the agent how to perform a Capacitor task correctly.
Capawesome Cloud and the Capawesome CLI — the capability layer that gives the agent everything it needs to actually build, sign, and deploy your app, including iOS builds from non-Mac machines.

This post focuses on the practical side: how to use both pieces together across the lifecycle of a real Capacitor app.

Setting Up Your Toolkit

The skills are agent-agnostic and work with Claude Code, Cursor, Windsurf, GitHub Copilot, and any other agent runtime that follows the agentskills.io spec.

Install all official Capawesome skills with a single command:

npx skills add capawesome-team/skills

For build, deploy, and live update commands, you'll also want the Capawesome CLI:

npm install -g @capawesome/cli@latest
npx @capawesome/cli login

In CI or non-interactive agent environments, log in with a token instead:

npx @capawesome/cli login --token

That's it. The agent now has both the knowledge and the tools to handle the rest.

Using AI Agents Across the Capacitor Lifecycle

With the toolkit in place, the same agent can support you from the first project scaffold all the way through long-term maintenance. The sections below walk through each stage in the order you'll typically hit it.

Creating a New App

The first stage of the lifecycle is the easiest place to lose time. Setting up a new Capacitor project means picking a framework, configuring the build tool, wiring up styling, and adding the iOS and Android platforms — each with their own quirks.

The ionic-app-creation skill takes care of all of it. Prompt your agent like this:

Use the ionic-app-creation skill to create a new Capacitor app with Ionic, React, and Tailwind CSS.

The agent scaffolds the project, installs the framework dependencies, sets up Tailwind, adds the iOS and Android platforms, and verifies that everything builds. You end up with a project that's ready to run on both platforms — no manual configuration required.

Adding Native Capabilities

Once your app is up and running, you'll usually want to add native capabilities — camera access, push notifications, NFC, biometrics, in-app purchases, and so on. The capacitor-plugins skill covers over 160 plugins from official, Capawesome, community, Firebase, MLKit, and RevenueCat sources.

For example, to add the NFC plugin and configure it correctly on both platforms:

Use the capacitor-plugins skill to install and configure the NFC plugin.

The agent installs the plugin, adds the iOS entitlements, updates the Info.plist, configures the Android manifest, and shows you a usage example for startScanSession(...). You stay in control of every change — the skill just makes sure the steps are correct and complete.

Building and Shipping to the App Store

Building a Capacitor app for the store is where things traditionally slow down: provisioning profiles, certificates, Xcode versions, Gradle config, and a Mac for iOS. The capawesome-cloud skill removes all of that. Combined with the Capawesome CLI, the agent can trigger a real iOS or Android build in the cloud and submit it directly to the App Store or Google Play.

A typical prompt looks like this:

Use the capawesome-cloud skill to build my app for iOS from the main branch and submit it to the App Store.

Under the hood, that becomes a single CLI call:

npx @capawesome/cli apps:builds:create \
  --platform ios \
  --git-ref main \
  --destination app-store

The build runs on Apple Silicon machines in the Capawesome Cloud, signs the app with credentials stored in your encrypted vault, and pushes the result to TestFlight. No Mac required, no certificates copied around, no manual upload to App Store Connect.

Pushing Hotfixes Instantly with Live Updates

Native builds are great for releases, but they're too slow for hotfixes. Waiting on App Store review for a one-line bug fix isn't an option when users are stuck on a broken screen. That's where the Live Update plugin comes in — it lets you push web layer changes (HTML, CSS, JavaScript) directly to your users' devices without going through the store.

Once the Live Update plugin is installed and configured, your agent can ship a hotfix with one prompt:

Use the capawesome-cloud skill to publish a live update from the main branch to the production channel.

Which translates to:

npx @capawesome/cli apps:liveupdates:create \
  --channel production \
  --git-ref main

The CLI bundles your web assets, uploads them, and rolls them out to the production channel. Users receive the update on the next app launch — no review, no waiting.

Debugging iOS Builds From Any OS — Without Committing

One of the most painful parts of Capacitor development is debugging iOS-specific build issues when you're on Windows or Linux. The traditional workaround is to commit speculative changes, push them, wait for CI, read the logs, repeat. It's slow and pollutes your git history with noise commits.

With Capawesome Cloud, you can skip all of that. The CLI accepts a local path and ships the current working directory straight to a cloud build machine:

npx @capawesome/cli apps:builds:create \
  --platform ios \
  --path .

Tell your agent to iterate against this command, and you can debug iOS build failures from any operating system without ever committing to git. The agent reads the build logs, suggests a fix, applies it, and reruns — all on your local working tree.

Maintaining the App Over Time

Most Capacitor maintenance is repetitive work that the agent can handle on its own once it has the right skill loaded.

To upgrade your app from Capacitor 8 to Capacitor 9:

Use the capacitor-app-upgrades skill to upgrade my app to Capacitor 9.

The agent detects your current version, checks prerequisites, and walks through the upgrade step by step. If the automated upgrade tool fails partway through, it falls back to the manual steps without losing track of where you are.

The same pattern applies to migrating from CocoaPods to Swift Package Manager:

Use the capacitor-app-spm-migration skill to migrate my iOS project from CocoaPods to Swift Package Manager.

The agent backs up your customized iOS project files, re-scaffolds the ios/ folder with SPM, restores the preserved files, re-syncs plugins, and verifies the build. The whole migration becomes a single conversation instead of a half-day chore.

Why This Setup Is Safe

Letting an AI agent run real builds and ship to production sounds risky on paper, but the architecture is designed so the agent never touches anything sensitive directly:

Credentials are encrypted at rest. Signing certificates, keystores, and API keys are stored in the Capawesome Cloud vault. The agent references them by name and never sees the raw material.
Builds run in isolated environments. Decryption only happens inside ephemeral build machines that are destroyed after the build completes.
The CLI returns structured JSON. Every command supports --json, so the agent can parse results reliably instead of scraping human-readable output.

In practice, this means you can give an agent a CI/CD-level task without giving it CI/CD-level permissions on your machine.

Conclusion

AI agents become genuinely useful for Capacitor development once you give them two things: framework-specific knowledge through the open source agent skills, and execution capability through the Capawesome CLI. With both in place, the same agent can scaffold a new app, install plugins, ship to the App Store, push hotfixes, debug iOS builds from Windows, and handle major version upgrades — all from a single conversation.

Have questions or want to share how you're using AI in your Capacitor workflow? Join the Capawesome Discord server.

How to Build and Deploy iOS Apps Without Owning a Mac

Robin — Tue, 07 Apr 2026 12:50:00 +0000

If you're building a Capacitor app on Windows or Linux, you've probably hit the same wall every cross-platform developer eventually runs into: shipping to the App Store requires macOS. Xcode, codesign, and the iOS simulator all live exclusively on Apple hardware, and Apple isn't planning to change that any time soon. The good news is that you don't actually need a Mac on your desk to build, sign, and ship an iOS app.

Why iOS Development Requires a Mac

Apple's entire iOS toolchain — Xcode, the iOS Simulator, xcodebuild, codesign, and the provisioning system — only runs on macOS. There's no official Linux or Windows version, and there's no supported way to produce a real .ipa file outside of an Apple-controlled environment. For a Capacitor or Ionic developer who lives in VS Code on Windows or Ubuntu, that's a hard blocker the moment you want to ship to TestFlight or the App Store.

Fortunately, "you need macOS" doesn't have to mean "you need to buy a Mac." There are three realistic ways to get access to a macOS build environment, and they trade off cost, flexibility, and setup effort in very different ways.

Three Ways to Build iOS Apps Without Owning a Mac

Option 1: Buy a Mac

The most straightforward route is also the most expensive. A Mac mini or MacBook Air gives you a permanent local build machine, full control over your Xcode versions, and the ability to run the iOS Simulator for debugging. The catch is the upfront cost (often well over $1,000 once you factor in storage and RAM), the ongoing maintenance, and the fact that the machine sits idle most of the time. For a solo developer who only occasionally ships an iOS build, that's a lot of hardware to babysit.

Option 2: Rent a Mac in the Cloud

Services like MacStadium and MacinCloud rent out real Mac hardware by the hour, day, or month. You SSH or VNC into a remote macOS instance and use it just like a local Mac. This avoids the upfront hardware cost and lets you scale up to faster machines when you need them — but you're still responsible for everything that happens inside the box: installing Xcode, managing certificates, writing build scripts, and keeping the environment in sync with your project. It's a Mac you don't own, but it's still a Mac you have to manage.

Option 3: Use a Mobile CI/CD Service

The third option is to skip the "raw Mac" entirely and use a purpose-built mobile CI/CD service such as Capawesome Cloud, Codemagic, or Bitrise. Instead of renting a machine, you describe your build in a config file (or click a button in a web UI), and the service spins up a clean, pre-configured macOS environment, runs the build, signs it, and hands you back an .ipa. You never have to touch Xcode yourself.

There's one trade-off worth knowing about: a CI/CD service is great for producing builds, but it can't replace a local Mac for interactive debugging. If you need to step through code in the iOS Simulator or attach a debugger to a physical device, you'll still want a real Mac (owned or rented) for that part of the workflow. For everything else — TestFlight builds, App Store submissions, ad-hoc test builds for your QA team — a CI/CD service is usually the fastest and cheapest path.

Building iOS Apps with Capawesome Cloud

Capawesome Cloud is a mobile CI/CD service built specifically for Capacitor and Ionic apps. Its Native Builds feature spins up isolated macOS build environments on M4 Pro hardware, handles Xcode, signing, and provisioning for you, and produces ready-to-install iOS artifacts in around two and a half minutes on average. It supports every iOS build type — Simulator, Development, Ad Hoc, App Store, and Enterprise — and integrates with GitHub, GitLab, Bitbucket, and Azure DevOps, including self-hosted instances.

You don't need Xcode on your machine. You don't need a Mac on your network. You just need a way to tell Capawesome Cloud to start a build — and there are two of those.

Two Ways to Trigger an iOS Build

From the Console

The Console is the web-based interface for managing your apps and builds. It's the easiest way to get started, especially if you want to browse logs, monitor progress, or trigger builds from any device — including your phone.

The prerequisite is that the Git repository hosting your iOS project is connected to your app in Capawesome Cloud. Once that's done:

Open your app in the Capawesome Cloud Console.
Go to the Builds page and click Build from Git.
Pick a Git reference (branch, tag, or commit), select iOS as the platform, and choose a build type.
Select a signing certificate with a matching provisioning profile.
Click Build.

That's it. You can close the tab and come back later, or watch the live logs stream in. When the build finishes, you'll find the .ipa ready for download — or automatically uploaded to TestFlight, if you've set up an App Store Publishing destination.

From the CLI

If you'd rather stay in your terminal — or you want to wire builds into your own CI/CD pipeline — the Capawesome CLI can trigger the same builds with a single command. And unlike the Console, the CLI doesn't require a connected Git repository: you can upload a local project directly.

Build from a Git reference (when a repository is connected):

npx @capawesome/cli apps:builds:create \
  --app-id  \
  --platform ios \
  --git-ref

Or build directly from a local directory, no Git connection required:

npx @capawesome/cli apps:builds:create \
  --app-id  \
  --platform ios \
  --path

The --path option is also handy when you do have a repository connected but want to test a quick local change without committing and pushing it first. You get the same cloud-built .ipa, just based on your working copy.

To grab the build artifact as soon as the build finishes, add the --ipa flag (or --apk for Android builds). The CLI will download it directly to your machine when the job completes:

npx @capawesome/cli apps:builds:create \
  --app-id  \
  --platform ios \
  --git-ref main \
  --ipa

That single command takes a Capacitor project on a Windows or Linux machine, builds it on a real Mac in the cloud, and drops the signed .ipa next to your project — no Xcode required.

See It in Action

Here's a short walkthrough of what triggering an iOS build in Capawesome Cloud actually looks like:

Final Thoughts

You don't need to buy a Mac, and you don't need to learn how to administer one in the cloud, just to ship a Capacitor app to the App Store. A purpose-built mobile CI/CD service like Capawesome Cloud handles the macOS side for you, leaves you to write your app on whatever OS you prefer, and works equally well from a polished web Console or a single CLI command. The only thing it can't do is replace your local simulator — for everything else, it's hard to beat.

If you want to go deeper on what Capawesome Cloud Native Builds can do under the hood, check out the Announcing Capawesome Cloud Native Builds post. And if you have questions or want to share what you're building, join us on the Capawesome Discord server or subscribe to the Capawesome newsletter to keep up with what's new.

DEV Community: Capawesome

Google Play Contacts Policy 2027 for Capacitor

Key Takeaways

What Does Google Play's Contacts Permissions Policy Require?

Why Does the Contact Picker Still Need READ_CONTACTS?

How to Pick a Contact Without the READ_CONTACTS Permission

What Changes on Android 17?

When Do You Still Need READ_CONTACTS?

How to Migrate Your Capacitor App

FAQ

When does Google Play's Contacts Permissions policy take effect?

Does the policy apply if my app targets Android 16?

Does this affect my app on iOS?

Can I still read a full contact after the user picks one?

What happens if I keep READ_CONTACTS without filing a declaration?

Does the property option work on older Android versions?

Conclusion

Capacitor Live Updates: Signing vs Encryption

Key Takeaways

The Trust Chain of a Live Update

What HTTPS Already Protects

What Code Signing Protects

Do Live Updates Need End-to-End Encryption?

When Confidentiality Matters: Self-Host Your Bundles

Live Update Security Best Practices

FAQ

Is end-to-end encryption more secure than code signing for OTA updates?

Can someone read my live update bundles?

What happens if the update service itself is compromised?

Does code signing work with self-hosted bundles?

Are live updates as secure as app store updates?

Conclusion

How to Detect the Network Status in a Capacitor App

Key Takeaways

Getting the Current Network Status

Listening for Network Changes

Why "Connected" Doesn't Mean Online

Detecting Metered and Data-Saving Connections

Checking Airplane Mode on Android

Building an Offline Banner

FAQ

What is the difference between connected and internetReachable?

How is this plugin different from the official Capacitor Network plugin?

Do I need any permissions to detect the network status?

Does network detection work in the browser?

Why is a VPN connection reported as UNKNOWN on iOS?

Conclusion

How to Use SQLite in Capacitor Apps

Why SQLite for Capacitor Apps?

Choosing a Capacitor SQLite Plugin

Installation

Platform Setup

Android

iOS

Web

Electron

Opening a Database with Schema Migrations

Running Queries

Transactions

Full-Text Search with FTS5

Key-Value Store Included

Encrypting the Database

Using ORMs: Drizzle, Kysely, and TypeORM

Error Handling

Performance Tips

Platform Limitations to Know

SQLite, Secure Preferences, or Vault?

Conclusion

How to Use Custom SQLite Extensions in Capacitor

What are custom SQLite extensions?

Why does each platform work differently?

Writing a loadable extension

Loading the extension on Android

Enable the bundled SQLite backend

Compile for each Android ABI

Bundle the native libraries

Load the extension

Loading the extension on iOS

Using a custom tokenizer in full-text search

Wrapping up

What is the difference between `connected` and `internetReachable`?

Why is a VPN connection reported as `UNKNOWN` on iOS?

Bonus: Tailwind CSS with `tailwindcss-safe-area`