DEV Community: Capgo

Capacitor live updates do not need the Play Store. Sideloaded APKs still get the zip.

Tori Chan — Tue, 25 Aug 2026 11:04:55 +0000

A question I still get from teams shipping internal Android apps: if the APK never goes through Play, can the WebView still receive a new zip?

Yes. The store installed the first binary. After that, the update server is just HTTPS. The plugin does not ask Google whether this device is allowed to change index.html.

I ship this for a living with @capgo/capacitor-updater. The same rule holds if you host the zip yourself. What matters is that the native plugin is already inside the APK, and that the APK is a real release (or a build you have explicitly allowed). Debug emulators are a different gate.

What the store is for

The store (or MDM, or adb install) puts a native binary on the device. That binary contains:

the Capacitor WebView
your plugins, including the updater
a first copy of the web assets (builtin)

Apple and Google allow you to refresh HTML, CSS, and JS that the WebView already loads. They do not allow you to swap native code that way. So a sideloaded APK can take a new JS bundle. It cannot take a new Gradle plugin through OTA.

If your change needs a new native plugin, you still rebuild the APK and have people install that binary. OTA is the web layer.

What the plugin actually checks

On launch the updater asks your server (or the URL you passed to download) for a bundle. It does not ask Play. A device that got the APK from a USB stick and a device that got it from Play look the same to the plugin.

Two filters people mix up with "store required":

Allow production builds vs development builds. A capgo channel can refuse debug binaries. Sideload a release APK if you want production-channel updates.
Allow physical devices vs emulators. Internal testers on real phones are fine. An emulator may be blocked on purpose.

Neither filter is "must be installed from Play."

Minimal path for an internal APK

Install the plugin, call notifyAppReady() in the entry file so a dead bundle rolls back, then either let auto-update talk to your server or pull a zip yourself:

import { CapacitorUpdater } from '@capgo/capacitor-updater'

await CapacitorUpdater.notifyAppReady()

const bundle = await CapacitorUpdater.download({
  url: 'https://example.com/releases/1.4.2.zip',
  version: '1.4.2',
})
await CapacitorUpdater.set({ id: bundle.id })

set reloads the WebView onto that folder. The next launch still has to call notifyAppReady() or native puts the previous folder back (default 10 seconds).

For a fleet of company phones, put the APK on MDM once. After that, ship zips. People should not reinstall the binary for a label change.

What still needs a new APK

New native plugin or Capacitor major
New Android permission
Signing / package name change
A WebView or OS version bump you do not already support

Everything else can be a zip.

The live-update docs start here: Capgo live updates. The store is how the binary arrived. It is not how the next JS bundle arrives.

How we detect a bad Capacitor OTA and roll it back in 10 seconds

Tori Chan — Tue, 25 Aug 2026 08:36:47 +0000

I ship JavaScript over the air for a living. The failure mode that still keeps me honest is not a bad button label. It is a bundle that never boots.

When we designed @capgo/capacitor-updater, I did not want a cloud dashboard to be the only undo button. The phone has to decide, by itself, that the new folder of HTML and JS is dead and put the last good folder back. That decision is a handshake. If JavaScript does not complete it, native code rolls the app back. The default window is ten seconds.

This is how that handshake actually works, what a crash looks like versus a hang, and how I test a deliberately broken bundle on a channel before I ever touch production.

The only signal that matters: `notifyAppReady()`

On every launch the native plugin serves a bundle — either the one that shipped in the binary (builtin) or a zip we downloaded earlier. Serving files is not the same as the app working. The WebView can open index.html and still die in the first module.

So the plugin starts a timer and waits for one method:

import { CapacitorUpdater } from '@capgo/capacitor-updater'

const { bundle } = await CapacitorUpdater.notifyAppReady()
console.log('native accepted', bundle.id, bundle.version)

I put that call in the entry file (main.ts, main.tsx, the first line of app.component.ts). Not after a router guard. Not after auth. The call confirms the bundle loaded and the JS runtime started. That is all it checks.

Call it on every launch. The timer does not remember yesterday. Do not delay it until the home feed loaded. A flaky API should not rewind a good update.

What the 10-second timer is (and is not)

The wait is appReadyTimeout in capacitor.config. Default is 10000 milliseconds:

/// <reference types="@capgo/capacitor-updater" />
import type { CapacitorConfig } from '@capacitor/cli'

const config: CapacitorConfig = {
  plugins: {
    CapacitorUpdater: {
      appReadyTimeout: 10000,
      autoDeleteFailed: true,
    },
  },
}

export default config

After you edit this file you still need npx cap sync and a store binary. Leave the default at 10 seconds unless boot cannot reach the entry file that fast.

Crash versus hang: same native verdict

Crash before the handshake (throw at the top of main.ts) and hang (never call notifyAppReady) get the same verdict: timer expires, previous bundle comes back.

A bug after the handshake does not roll back.

import { CapacitorUpdater } from '@capgo/capacitor-updater'

CapacitorUpdater.addListener('updateFailed', (state) => {
  console.log('rolled back from', state.bundle?.id, state.bundle?.version)
})


const failed = await CapacitorUpdater.getFailedUpdate()
if (failed) {
  console.log('last failed bundle', failed.bundle)
}

autoDeleteFailed defaults to true.

How I test a broken bundle (on a channel, not on production)

npx @capgo/cli@latest channel add rollback-test com.example.app

npx @capgo/cli@latest channel set rollback-test com.example.app --self-assign

npx @capgo/cli@latest bundle upload --channel rollback-test

For a QA binary set defaultChannel: 'rollback-test' then npx cap sync. Ship a bundle that throws at the top of main.ts, or comment out notifyAppReady. One test device. About ten seconds later you should be on the previous bundle.

The full rollback surface is in the rollbacks docs.

What I tell my own team

Treat notifyAppReady() like main() returning. Keep appReadyTimeout at 10 seconds unless you have measured a boot that cannot hit the entry file in time. Practice on a named channel with one device, then delete the channel when you are done.

The 10 seconds are not a marketing number. They are the default native timer. Miss the handshake, and that is how long a user stares at a dead update before we put their app back.

How we detect a bad Capacitor OTA and roll it back in 10 seconds

Tori Chan — Fri, 21 Aug 2026 16:39:54 +0000

I ship JavaScript over the air for a living. The failure mode that still keeps me honest is not a bad button label. It is a bundle that never boots.

This is how that handshake actually works, what a crash looks like versus a hang, and how I test a deliberately broken bundle on a channel before I ever touch production.

The only signal that matters: `notifyAppReady()`

So the plugin starts a timer and waits for one method:

import { CapacitorUpdater } from '@capgo/capacitor-updater'

const { bundle } = await CapacitorUpdater.notifyAppReady()
console.log('native accepted', bundle.id, bundle.version)

Call it on every launch. The timer does not remember yesterday. Do not delay it until the home feed loaded. A flaky API should not rewind a good update.

What the 10-second timer is (and is not)

The wait is appReadyTimeout in capacitor.config. Default is 10000 milliseconds:

/// <reference types="@capgo/capacitor-updater" />
import type { CapacitorConfig } from '@capacitor/cli'

const config: CapacitorConfig = {
  plugins: {
    CapacitorUpdater: {
      appReadyTimeout: 10000,
      autoDeleteFailed: true,
    },
  },
}

export default config

After you edit this file you still need npx cap sync and a store binary. Leave the default at 10 seconds unless boot cannot reach the entry file that fast.

Crash versus hang: same native verdict

Crash before the handshake (throw at the top of main.ts) and hang (never call notifyAppReady) get the same verdict: timer expires, previous bundle comes back.

A bug after the handshake does not roll back.

import { CapacitorUpdater } from '@capgo/capacitor-updater'

CapacitorUpdater.addListener('updateFailed', (state) => {
  console.log('rolled back from', state.bundle?.id, state.bundle?.version)
})

const failed = await CapacitorUpdater.getFailedUpdate()
if (failed) {
  console.log('last failed bundle', failed.bundle)
}

autoDeleteFailed defaults to true.

How I test a broken bundle (on a channel, not on production)

npx @capgo/cli@latest channel add rollback-test com.example.app
npx @capgo/cli@latest channel set rollback-test com.example.app --self-assign
npx @capgo/cli@latest bundle upload --channel rollback-test

The full rollback surface is in the rollbacks docs.

What I tell my own team

The 10 seconds are not a marketing number. They are the default native timer. Miss the handshake, and that is how long a user stares at a dead update before we put their app back.

DEV Community: Capgo

Capacitor live updates do not need the Play Store. Sideloaded APKs still get the zip.

What the store is for

What the plugin actually checks

Minimal path for an internal APK

What still needs a new APK

How we detect a bad Capacitor OTA and roll it back in 10 seconds

The only signal that matters: notifyAppReady()

What the 10-second timer is (and is not)

Crash versus hang: same native verdict

How I test a broken bundle (on a channel, not on production)

What I tell my own team

How we detect a bad Capacitor OTA and roll it back in 10 seconds

The only signal that matters: notifyAppReady()

What the 10-second timer is (and is not)

Crash versus hang: same native verdict

How I test a broken bundle (on a channel, not on production)

What I tell my own team

The only signal that matters: `notifyAppReady()`

The only signal that matters: `notifyAppReady()`