---
title: Live Update Troubleshooting
description: Fix common Capacitor and Cordova Live Update issues — no update delivered, updates not applied, the app hanging after a reload, crashes after an update, and signature failures.
---

# Troubleshooting

Most Live Update issues can be diagnosed from the [Logs](logs.md) view in the Console, which shows each device-to-cloud request, the channel it requested, and the bundle it was served. Start there, then match your symptom below.

## Check the native logs

The SDK also prints diagnostic messages on the device itself. When something doesn't behave as expected, run the app on a device or simulator and watch the native logs for any errors or warnings from the Live Update SDK — they often point straight at the cause:

- **Android** — view Logcat in Android Studio, or run `adb logcat` from the terminal.
- **iOS** — open the Xcode console while the app is running.

## No update is delivered to the device

Check these causes, roughly in order of likelihood:

1. **Channel mismatch** — the device is subscribed to a different channel than you published to. Check the [Logs](logs.md) to see which channel the device requested. This is the most common cause when using versioned channels.
2. **Native-version incompatibility** — the bundle is restricted to a native version range that doesn't include the device. See [Binary-Compatible Changes](binary-compatible-changes.md).
3. **Rollout** — the bundle is at less than 100% and this device isn't in the rollout group. See [Roll out gradually](rollouts.md).
4. **Strategy not triggering** — with `autoUpdateStrategy: none` and no manual `sync()`, no check happens. With `background`, checks are throttled to once every 15 minutes — force-close and restart to trigger one immediately.
5. **Blocked or rolled-back bundle** — `autoBlockRolledBackBundles` blocks a bundle that previously failed to start. See [Roll back a release](rollbacks.md).
6. **Signature rejected** — if the bundle is signed but the app's configured public key doesn't match, the bundle is rejected. See [Sign your bundles](code-signing.md).
7. **Quota or lifecycle** — your MAU or data transfer [limit](limits.md) was reached, or the bundle expired or was deleted.
8. **Network** — the device can't reach Capawesome Cloud, or a custom `serverDomain` is misconfigured. Check the [status page](https://status.capawesome.io){:target="_blank"} to rule out a service incident.

## An update is downloaded but not applied

The bundle is staged but the WebView still shows the old version. This usually means the app hasn't reloaded yet:

- With `background`, the new bundle is applied on the **next** app launch — force-close and restart.
- If you use a manual strategy, make sure you call `reload()` after the bundle is staged. See [Choose an Update Strategy](update-strategies.md).

## The app hangs after a reload, but works after a force quit

If the app shows a blank or loading screen after `reload()`, but the update is applied correctly after a force quit, the bundle was most likely applied as expected and the new page is stuck instead. Log the bundle ID returned by `getCurrentBundle()` as early as possible at app start to confirm which bundle is running.

`reload()` reloads the WebView without restarting the native process, so resources of the web layer that hold an exclusive lock are not released automatically and can prevent the new page from starting. A force quit starts a new process and releases these resources, which is why the update seems to be applied only after a restart.

The most common cause is IndexedDB. The Firebase JS SDK, for example, holds an IndexedDB lease as long as Firestore offline persistence is enabled — terminate the client before calling `reload()`. Keep in mind that persistence may be active even if you try to exclude WebViews, because guards that detect the browser by user agent usually also match the `WKWebView` on iOS. On Android, the problem is less likely to occur because Chromium recovers from a stale lease. Other candidates are WebSockets, Web Locks and service workers. If you cannot release these resources, apply the new bundle on the next app launch instead of reloading in place.

## The app crashes or rolls back after an update

- A bundle that depends on a native feature the installed binary doesn't have will crash on launch. Make updates [version-compatible](binary-compatible-changes.md).
- If you use automatic rollback, the app reverts to the built-in bundle shipped with the installed native app version when `ready()` isn't called within `readyTimeout`. Make sure you call `ready()` early at app start. See [Roll back a release](rollbacks.md).

## Signature verification fails

The bundle's signature doesn't match the public key in your app config. Confirm you're signing with the matching private key and that the public key in your config is correct. See [Sign your bundles](code-signing.md).

## Still stuck?

Reach out via [Support](../../support/index.md) with the relevant entries from the [Logs](logs.md) view.