DEV Community: Capawesome

Background Geolocation in Capacitor Without Losing Positions

Robin — Thu, 03 Sep 2026 17:03:42 +0000

Most background location setups in Capacitor apps share a silent failure mode: positions are collected in JavaScript, and JavaScript stops the moment the operating system suspends the web view. The result is a track with holes, discovered in production. We just released the Capacitor Background Geolocation plugin to fix exactly that: every position is recorded natively into an SQLite queue and uploaded to your server, whether or not the web view is awake.

Permissions the way the platforms actually work

Neither platform lets you ask for foreground and background location in one prompt, so the plugin doesn't pretend otherwise:

import { BackgroundGeolocation } from '@capawesome-team/capacitor-background-geolocation';

let status = await BackgroundGeolocation.requestPermissions({
  permissions: ['location', 'notifications'],
});
if (status.location === 'granted') {
  status = await BackgroundGeolocation.requestPermissions({
    permissions: ['backgroundLocation'],
  });
}

Watch sessions with real tuning knobs

import { Accuracy, BackgroundGeolocation } from '@capawesome-team/capacitor-background-geolocation';

await BackgroundGeolocation.startWatching({
  accuracy: Accuracy.High,
  distanceFilter: 10,
  androidNotification: {
    title: 'Location Tracking',
    text: 'Your location is being tracked.',
  },
});

androidNotification is mandatory because Android requires a foreground service with a persistent notification — the plugin makes that explicit instead of inventing one. There's deliberately no accelerometer-driven motion-detection state machine; battery is controlled through predictable knobs (accuracy, distanceFilter, androidInterval, iosPausesAutomatically).

The queue is the source of truth

Enable it once and every position is written natively:

await BackgroundGeolocation.setConfig({ maxSize: 50000 });

The positionChange event becomes what it honestly is — a live feed for your UI — while the queue survives restarts and force-quits. Drain it with getQueuedPositions(...) and acknowledge with deleteQueuedPositions({ upToId }); ids are strictly increasing, so a crash between reading and persisting never loses a position.

Upload without JavaScript

Add a url and the queue uploads itself in batches:

await BackgroundGeolocation.setConfig({
  url: 'https://api.example.com/positions',
  batchSize: 100,
  flushInterval: 60000,
  headers: { Authorization: 'Bearer ...' },
});

Delivery is at least once with a documented status-code contract: 2xx acknowledges, 401/408/429/5xx retry with exponential backoff, anything else drops the batch permanently so it can't block the queue. Deduplicate by position id on the server and delivery is effectively exactly-once. You can test the whole pipeline against the free Background Geolocation Playground before your endpoint exists.

One honest limit: a force-quit ends the watch session — that's an OS restriction. Queued positions survive and upload on the next start, and OS-managed geofencing (a separate plugin) covers relaunch scenarios.

The plugin is part of Capawesome Insiders and requires Capacitor 8+. The full announcement covers the complete server contract and the battery trade-offs.

Fixing the Invisible Camera Preview in Capacitor Barcode Scanners

Robin — Wed, 02 Sep 2026 17:00:55 +0000

Search any Capacitor forum for barcode scanning and one bug dominates: the camera preview is invisible. The classic approach renders the camera behind the web view and requires your entire app to be transparent — which works until an Ionic modal, a page transition, or a dark theme paints a background over it.

We took a different route with the embedded mode of the Capacitor Barcode Scanner plugin: the camera preview is a native view positioned inside your app layout, above the web view, so HTML can never cover it by accident.

Position the camera with a placeholder element

Your markup reserves the space, and the element's bounding rectangle becomes the frame:

import { BarcodeScanner, LensFacing } from '@capawesome-team/capacitor-barcode-scanner';

const getScanFrame = () => {
  const rect = document.querySelector('#scanner').getBoundingClientRect();
  return { x: rect.x, y: rect.y, width: rect.width, height: rect.height };
};

await BarcodeScanner.addListener('barcodesScanned', (event) => {
  console.log('Scanned barcodes:', event.barcodes);
});
await BarcodeScanner.startScan({
  frame: getScanFrame(),
  lensFacing: LensFacing.Back,
});

Detected barcodes stream in continuously until stopScan(). A duplicateTimeout (default 1500 ms) prevents the same barcode from flooding your handler, formats restricts detection to what you expect, and detectionArea limits detection to a region within the frame.

Keep the frame in sync

The native view doesn't reflow with your CSS, so update it when the layout changes:

window.addEventListener('resize', async () => {
  await BarcodeScanner.setScanFrame({ frame: getScanFrame() });
});

Overlays are an explicit opt-in

If your design needs HTML drawn over the camera (a viewfinder, detection markers), set placement: PreviewPlacement.Behind and the preview renders behind the web view. That mode has the same transparency requirement as the classic approach — but now it's a scoped choice for one screen you design around, not a global precondition for scanning at all.

It works on the web, too

The embedded mode and readBarcodesFromImage(...) are supported on the web via the BarcodeDetector API (with a recommended polyfill for browsers without it). Torch, zoom, and the ready-made fullscreen scanner are native-only.

The full guide also covers torch and zoom control, camera selection, the themeable fullscreen scanner, and migrating from the ML Kit Barcode Scanning plugin.

Announcing the Capacitor MapLibre Plugin

Robin — Fri, 28 Aug 2026 14:00:56 +0000

Showing a native map in a Capacitor app has practically meant one thing: Google Maps, plus the billing account it requires before the first tile loads. We just released the Capacitor MapLibre plugin, the first native MapLibre integration for Capacitor — free, open stack, and no vendor account required by the plugin.

It renders maps with the native MapLibre SDKs on Android and iOS and with MapLibre GL JS on the Web, so one TypeScript API covers all three platforms.

How the Native Rendering Works

On Android and iOS, the map is a native view rendered behind the web view, positioned by an empty element in your DOM. The contract is small: the map element stays empty, and it and every ancestor covering the map region use background: transparent — otherwise the web view paints over the map.

The upside of this architecture: any DOM element that isn't an ancestor of the map element renders above the map. Floating action buttons, bottom sheets, and dialogs just work. The plugin also keeps the native view in sync with the element's position and size automatically, including while the page scrolls.

Create a Map

import { MapLibre } from '@capawesome/capacitor-maplibre';

const createMap = async () => {
  await MapLibre.createMap({
    center: { latitude: 48.137154, longitude: 11.576124 },
    elementId: 'map',
    mapId: 'my-map',
    styleUrl: 'https://basemaps.cartocdn.com/gl/positron-gl-style/style.json',
    zoom: 12,
  });
};

Every method takes the mapId, so multiple maps can run at the same time.

Markers with Animated Updates

Markers take custom icons with configurable anchor, size, and rotation, and can be moved with a smooth animation — the building block for live vehicle tracking:

import { MapLibre, MarkerIconAnchor } from '@capawesome/capacitor-maplibre';

const addAndMoveMarker = async () => {
  await MapLibre.addMarker({
    mapId: 'my-map',
    marker: {
      coordinates: { latitude: 48.137154, longitude: 11.576124 },
      iconAnchor: MarkerIconAnchor.Center,
      iconSize: { height: 32, width: 32 },
      iconUrl: 'https://example.com/marker.png',
      id: 'my-marker',
    },
  });
  await MapLibre.updateMarkerById({
    animate: true,
    animationDuration: 1000,
    coordinates: { latitude: 48.370545, longitude: 10.89779 },
    mapId: 'my-map',
    markerId: 'my-marker',
    rotation: 90,
  });
};

GeoJSON Layers

For routes, areas, and anything your backend already stores as GeoJSON, add a source and style it with line, fill, or circle layers:

import { LayerType, MapLibre } from '@capawesome/capacitor-maplibre';

const addGeoJson = async () => {
  await MapLibre.addGeoJsonSource({
    mapId: 'my-map',
    sourceId: 'my-source',
    url: 'https://example.com/routes.geojson',
  });
  await MapLibre.addLayer({
    layerId: 'my-layer',
    mapId: 'my-map',
    paint: { lineColor: '#3887be', lineWidth: 4 },
    sourceId: 'my-source',
    type: LayerType.Line,
  });
};

User Location

Request the location permission, then display and follow the user:

import { MapLibre, UserTrackingMode } from '@capawesome/capacitor-maplibre';

const enableUserLocation = async () => {
  let status = await MapLibre.checkPermissions();
  if (status.location === 'prompt') {
    status = await MapLibre.requestPermissions();
  }
  if (status.location !== 'granted') {
    return;
  }
  await MapLibre.enableUserLocation({
    mapId: 'my-map',
    trackingMode: UserTrackingMode.Follow,
  });
};

Map Styles and API Keys

The plugin renders any style following the MapLibre Style Spec. "No API key required by the plugin" is not the same claim as "free tiles": the style decides where tiles come from. Free providers such as OpenFreeMap and CARTO basemaps exist, while commercial providers such as MapTiler use their own keys. Follow your provider's attribution requirements, and don't ship the default demo style — it's for testing only.

Availability

The plugin is free, requires Capacitor 8 or later, and one known limitation applies: offline tile management is not part of this version. The full announcement is on our blog: Announcing the Capacitor MapLibre Plugin, and the plugin documentation covers the complete API.

Questions or feedback? Drop a comment — happy to answer.

Announcing the Capacitor File Transfer Plugin

Robin — Thu, 27 Aug 2026 14:00:49 +0000

If you've ever shipped a download feature in a Capacitor app, you know the failure modes: the user switches apps halfway through a 500 MB file, the operating system kills the process, or a big transfer quietly eats someone's mobile data plan. The official @capacitor/file-transfer plugin covers foreground transfers; we just released the Capacitor File Transfer plugin to handle everything around them.

Transfers as Tasks

The core idea: a transfer is a first-class, persisted object. Starting one returns an identifier immediately, the work runs in native code that outlives your web view (a background URLSession on iOS, a dataSync foreground service on Android), and the state can be queried later — even after an app restart.

Start a Download

import { FileTransfer } from '@capawesome-team/capacitor-file-transfer';

const startDownload = async () =&gt; {
  const { id } = await FileTransfer.startDownload({
    url: 'https://example.com/file.zip',
    path: '/path/to/destination/file.zip',
    headers: {
      Authorization: 'Bearer ',
    },
    network: 'unmetered',
    maxRetries: 3,
    androidNotification: {
      title: 'Downloading file',
      text: 'The file is being downloaded.',
    },
  });
  return id;
};

network: 'unmetered' keeps the download off mobile data, and maxRetries retries with backoff on network errors instead of failing on the first dropped packet.

Uploads, Including S3 Presigned URLs

Uploads send multipart/form-data by default and switch to a raw binary body for presigned URLs:

import { FileTransfer } from '@capawesome-team/capacitor-file-transfer';

const uploadToPresignedUrl = async () =&gt; {
  const { id } = await FileTransfer.startUpload({
    url: 'https://example.com/presigned-url',
    path: '/path/to/source/file.jpg',
    method: 'PUT',
    uploadType: 'binary',
    mimeType: 'image/jpeg',
  });
  return id;
};

The file streams straight from the file system into the request — no base64 detour, no blob in JavaScript memory.

Events That Survive Backgrounding

Transfers report their state through transferProgress, transferCompleted, and transferFailed events. The important detail: completed and failed events that occur while no listener is registered are retained and delivered as soon as a listener is added, so a download that finishes while your app is in the background still reaches your code on the next launch.

Pause, Resume, Restore

Downloads can be paused and resumed at any time — even after the process was killed, via resume data on iOS and HTTP Range requests on Android. And because transfers are persisted, getTransfers() rebuilds a download manager UI after a restart:

import { FileTransfer } from '@capawesome-team/capacitor-file-transfer';

const restoreTransferList = async () =&gt; {
  const { transfers } = await FileTransfer.getTransfers();
  return transfers.filter(transfer =&gt; transfer.state === 'running' || transfer.state === 'paused');
};

Uploads cannot be paused: plain HTTP uploads have no standard resume mechanism, so the plugin rejects instead of faking a pause that would restart from zero anyway.

What Happens in Each App State

Instead of leaving it to experimentation, the behavior is documented per platform:

App state	Android	iOS
Foreground	Runs.	Runs.
Backgrounded	Runs in the `dataSync` foreground service.	Runs in the background `URLSession`.
Killed by the OS	Interrupted; restored as `failed`, downloads resumable.	Continued by the OS and delivered on relaunch.
Force-quit by the user	Interrupted; restored as `failed`, downloads resumable.	Canceled by the OS (documented iOS behavior).

Resuming an interrupted download requires the server to support the HTTP Range header.

Migrating from @capacitor/file-transfer

The switch is mostly a rename plus a change of model — transfers become asynchronous tasks:

`@capacitor/file-transfer`	`@capawesome-team/capacitor-file-transfer`
`downloadFile({ url, path })`	`startDownload({ url, path })`, resolves with `{ id }`
`uploadFile({ url, path })`	`startUpload({ url, path })`, resolves with `{ id }`
`addListener('progress', ...)`	`addListener('transferProgress', ...)`
No equivalent	`transferCompleted` and `transferFailed` events
No equivalent	`pauseTransferById`, `resumeTransferById`, `cancelTransferById`
No equivalent	`getTransferById`, `getTransfers`

Availability

The plugin is part of the Capawesome Insiders subscription and requires Capacitor 8 or later. The full announcement is on our blog: Announcing the Capacitor File Transfer Plugin, and the plugin documentation covers the complete API.

Questions or feedback? Drop a comment — happy to answer.

Announcing the Capacitor Health Plugin

Robin — Wed, 26 Aug 2026 19:30:07 +0000

Health data on mobile lives in two stores: Apple HealthKit on iOS and Health Connect on Android. If you build a fitness or health app with Capacitor, you normally end up writing two integrations that disagree on permissions, sleep modeling, and even what a "workout" is. We just released the Capacitor Health plugin to solve exactly that: one strictly typed API that reads, writes, and aggregates data from both stores.

Why a Health Plugin Now

The timing follows the platforms. The Google Fit APIs shut down at the end of 2026, and Health Connect takes over as the health store on Android, while HealthKit has held that role on iOS all along. Any cross-platform health integration you build today should target these two stores — and ideally without maintaining two data models in your app code.

Aggregation First

Most health plugins hand you raw record lists and leave the math to you. That breaks the moment a user wears a smartwatch: the watch and the phone both record steps for the same minutes, and summing the records in JavaScript counts that overlap twice.

Both HealthKit and Health Connect solve this with native aggregation queries that deduplicate sources before returning a number, so the plugin is built around them. A week of daily step totals is one call:

import { DataType, Health } from '@capawesome-team/capacitor-health';

const readDailySteps = async () => {
  const { buckets } = await Health.aggregate({
    dataType: DataType.Steps,
    startDate: new Date(Date.now() - 7 * 24 * 60 * 60 * 1000).toISOString(),
    endDate: new Date().toISOString(),
    bucket: 'day',
    operations: ['sum'],
  });
  return buckets.map((bucket) => bucket.values[0].value);
};

The day, week, and month buckets are calendar-aware and follow the device's time zone. Cumulative data types such as steps, distance, and calories support sum; sampled types such as heart rate and weight support average, maximum, and minimum. An unsupported combination rejects with the INVALID_AGGREGATION error code instead of resolving with silently empty results, so a mistyped query fails in development instead of shipping as a dashboard full of zeros.

Availability and Permissions

Health Connect exists in three states on Android: available, not installed, or unsupported by the device. On Android 9 to 13 it's a separate app the user may not have; on Android 14 and later it's part of the operating system:

import { Health } from '@capawesome-team/capacitor-health';

const checkAvailability = async () => {
  const { available, reason } = await Health.isAvailable();
  if (!available && reason === 'health-connect-not-installed') {
    await Health.installHealthConnect();
  }
  return available;
};

Permissions are requested per data type and separately for reading and writing:

import { DataType, Health } from '@capawesome-team/capacitor-health';

const requestPermissions = async () => {
  const { permissions } = await Health.requestPermissions({
    read: [DataType.Steps, DataType.HeartRate, DataType.Sleep],
    write: [DataType.Weight],
  });
  return permissions;
};

An Honest Permission Model

Here's a HealthKit detail that surprises most developers: iOS deliberately hides whether a read permission was granted. A denied permission that is distinguishable from missing data would leak sensitive information — an app that knows it was denied blood glucose access could conclude the user is likely diabetic.

The plugin reports iOS read permissions as prompt before the first request and unknown afterwards, never as granted. Reporting granted would be an invented value, so the plugin doesn't do it. Design your app around the presence of data: request the permissions, query, and show a helpful empty state when nothing comes back.

Reading and Writing Records

When you need individual samples instead of aggregates, readRecords() returns them with timestamps and source, and writeRecord() logs the record types apps commonly write:

import { DataType, Health } from '@capawesome-team/capacitor-health';

const readHeartRateSamples = async () => {
  const { records } = await Health.readRecords({
    dataType: DataType.HeartRate,
    startDate: new Date(Date.now() - 24 * 60 * 60 * 1000).toISOString(),
    endDate: new Date().toISOString(),
  });
  return records;
};

const logWeight = async () => {
  await Health.writeRecord({
    dataType: DataType.Weight,
    startDate: new Date().toISOString(),
    value: 71.5,
  });
};

Workouts have their own reader: readWorkouts() returns exercise sessions with type, duration, and totals, whether logged by your app or another one.

Passing App Review

Health integrations fail review more often than they fail at runtime. Every Android app integrating with Health Connect must complete the Health apps declaration in the Google Play Console and provide a privacy policy; Apple reviews health apps against App Review Guideline 5.1.3. The plugin documentation includes dedicated sections for both, so the policy work is part of the setup instead of a surprise at submission time.

Availability

The Capacitor Health plugin covers around 20 data types, requires Capacitor 8 or later, and is available today as part of the Capawesome Insiders subscription. The full announcement with more details is on our blog: Announcing the Capacitor Health Plugin.

Questions or feedback? Drop a comment — happy to answer.

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.

DEV Community: Capawesome

Background Geolocation in Capacitor Without Losing Positions

Permissions the way the platforms actually work

Watch sessions with real tuning knobs

The queue is the source of truth

Upload without JavaScript

Fixing the Invisible Camera Preview in Capacitor Barcode Scanners

Position the camera with a placeholder element

Keep the frame in sync

Overlays are an explicit opt-in

It works on the web, too

Announcing the Capacitor MapLibre Plugin

How the Native Rendering Works

Create a Map

Markers with Animated Updates

GeoJSON Layers

User Location

Map Styles and API Keys

Availability

Announcing the Capacitor File Transfer Plugin

Transfers as Tasks

Start a Download

Uploads, Including S3 Presigned URLs

Events That Survive Backgrounding

Pause, Resume, Restore

What Happens in Each App State

Migrating from @capacitor/file-transfer

Availability

Announcing the Capacitor Health Plugin

Why a Health Plugin Now

Aggregation First

Availability and Permissions

An Honest Permission Model

Reading and Writing Records

Passing App Review

Availability

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?

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

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