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.

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.

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:

1. 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.
2. Stick with zip. Unless you have evidence delta will work, zip is smaller in practice.
3. 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.