Skip to content

Ship the fix today. The store build can follow.

Signed live updates for Capacitor apps. Roll out to a percentage, see who has it, and roll back when a release fails to start.

Release 4.2.1production

Rolling out

  1. Build
  2. Sign
  3. Roll out
  4. Watch
  5. Widen

5%

12 of 240 devices on 4.2.1

5%

Five percent first. Widen when the numbers look right.

A simulation of one release on 240 devices. Drag the rollout to widen it, or make a device fail to start.

Store review takes as long as it takes.

Your JavaScript doesn’t have to wait in that line. A copy fix, a broken screen or a bad API call lives in your web bundle, and Native Update carries that bundle to every installed copy of your app today.

Store build

  1. Build the binary
  2. Submit it
  3. Review, as long as it takes
  4. Users update when the store offers it

Live update

  1. Build the web bundle
  2. Sign it
  3. Roll out to 5%
  4. Watch
  5. Widen to 100%

Live updates carry web-layer changes; native changes still ship through the store.

Every release crosses the same desk.

Five steps, the same every time, from the dashboard or the CLI.

  1. 1

    Build

    Run your usual web build. The bundle is the folder Capacitor already ships.

    npx native-update bundle create ./dist --version 4.2.1
  2. 2

    Sign

    Sign it with your private key. The key stays with you; the app holds the public half.

    npx native-update bundle sign ./bundle.zip --key ./keys/private.pem
  3. 3

    Roll out

    Upload it and choose who gets it first. Five percent is a good start.

    npx native-update deploy ./dist --app com.example.app --rollout 5 --wait
  4. 4

    Watch

    The dashboard counts the devices on the release and any that failed to start, so you never have to guess who has the fix.

  5. 5

    Widen or roll back

    Widen when the numbers look right, or roll back with one click and keep the release for later.

    npx native-update builds rollout com.example.app 42 --percent 25

Signed before it leaves your machine. Checked before it runs.

Every bundle carries a SHA-256 checksum and an RSA-SHA256 signature. The server checks both when you upload, and the plugin checks them again on the device before it installs anything.

  • The private key stays on your machine or in your CI secrets. The app only holds the public key.
  • A bundle whose checksum or signature doesn’t match is refused, and the app keeps the bundle it has.
  • Downloads use HTTPS only. The plugin refuses an update URL that isn’t.
How bundle signing works (opens in a new tab)

bundle-4.2.1.zip

example
SHA-256
3f9a0c7e5b21d84a9e6f1c03b7d2a5e8 41c9f0b6e2d7a3c5f8b1e4d9a0c6c21e
Signature
RSA-SHA256, signed with keys/private.pem
On upload
Checksum and signature match
On the device
Verified before install

If a bundle fails to start, the app goes back by itself.

Call notifyAppReady() once your app has booted. If a new bundle never gets that far, the native layer reverts it after two cold starts and the app opens on the last good bundle.

  1. 4.2.1

    New bundle installed

    Downloaded and verified in the background.

  2. Launch

    The app starts on it

    On the next cold start.

  3. notifyAppReady()

    Boot confirmed

    The bundle is kept.

  4. Counted

    Device on 4.2.1

    The dashboard adds it to the release.

  5. Two cold starts

    No confirmation

    The native layer stops trusting the bundle.

  6. Back to 4.2.0

    Last good bundle

    Counted as a failed start on the dashboard.

With the call in place, the release is kept and counted.

The rest of a release, on the same desk.

Delta patches

When a few files change, the plugin downloads a delta (NUDELTA/1) instead of the whole bundle. If a delta can’t apply, it falls back to the full bundle.

  • main.3f9a.jschanged
  • styles.b81c.csschanged
  • index.htmlunchanged
  • vendor.7d20.jsunchanged
  • assets/logo.svgunchanged

Channels

Keep production, staging and your own channels apart. Promote a build from staging to production without uploading it again.

productionstagingbeta-testers

Store-update prompts

When a release needs native code, tell users a store update is ready and open the store page for them.

In-app review

The store’s own review prompt, at a moment you choose.

Release from CI, with a token made for it.

The CLI and the public management API use nu_pat_ access tokens, scoped to the apps you choose. Uploads are queued, and --wait blocks until the release is live, so a failed upload fails the job.

Each app’s API key can be restricted to your web origins, your Android package and signing certificate, or your iOS bundle id.

Public API reference (opens in a new tab)
# sign, upload, and start at 5% export NATIVE_UPDATE_TOKEN=nu_pat_... npx native-update bundle sign ./bundle.zip --key ./keys/private.pem npx native-update deploy ./dist --app com.example.app \ --version 4.2.1 --rollout 5 --wait # widen when the numbers look right npx native-update builds rollout com.example.app 42 --percent 25

Every check, where it runs, and what happens when it fails.

CheckWhere it runsWhen it fails
SHA-256 checksumThe server on upload, the device before installThe bundle is refused
RSA-SHA256 signatureThe server on upload, the device before installThe bundle is refused
App startThe device, on the first launch of a new bundleBack to the last good bundle after two cold starts
API key restrictionThe server, on every update checkRefused with API_KEY_RESTRICTED
Access token scopeThe server, on every public API callAnswers 404, so other apps can’t be discovered
HTTPSThe plugin, before any downloadAn HTTP update URL is refused

What a live update can change, and what it can’t.

Ships today, over the air

  • JavaScript and TypeScript output
  • HTML, CSS and your web routes
  • Images, fonts and other web assets
  • Copy, translations and configuration inside the bundle

Still ships through the store

  • Native code: Kotlin, Java, Swift
  • A new Capacitor plugin or a plugin upgrade with native parts
  • New permissions in the manifest
  • The app icon, splash screen and store version

For those, ship a store build, and let Native Update prompt users to install it.

Made for the people who ship Capacitor apps, at any size.

You ship alone

Free covers 30 apps and 5,000 monthly active users, with every feature included. Pro removes the app limit when one of them takes off.

Free or Pro

You ship as a team

Team gives everyone one workspace, and each member adds 100,000 monthly active users to the team’s limit. It starts at 3 seats.

Team

You ship for clients

Give each client app its own API keys and channels, and let the client test a release on staging before production gets it.

Any plan

Two assistants, and both of them listen.

Type or press Speak. One drafts your release notes from the commits in a release; the other answers setup questions and shows the docs page the answer came from.

Release notes writer

Commits in 4.2.1

The draft appears here. You edit it before it goes out with the release.

Docs assistant

Ask about

Pick a question, or press Speak and ask your own.

Every feature on every plan. The plans differ in scale.

Free

$0 forever

Apps
30
Monthly active users
5,000
Workspace
Just you

Pro

$9.99 per month

Apps
Unlimited
Monthly active users
50,000
Workspace
Just you

Team

$8.99 per seat per month

Apps
Unlimited
Monthly active users
100,000 per member
Workspace
Shared, 3 seats minimum

A monthly active user is a unique device that checks for an update at least once in a rolling 30-day window. Prices in USD.

From install to the first rollout, in six steps.

Open the walkthrough
  1. 1

    Install the plugin

    yarn add native-update
  2. 2

    Create the app and its API key

    In the dashboard, or with the CLI.

  3. 3

    Make a signing key

    npx native-update keys generate
  4. 4

    Upload a bundle at 5%

    Signed, checked, queued.

  5. 5

    Watch, then widen

    Or roll back with one click.

  6. 6

    Add store and review prompts

    For the releases that need the store.

Support Native Update.

Happy on Free, or not ready for a plan, and still want to give something back? Choose an amount. It pays for the servers that check every bundle and for the time we put into the plugin.

By continuing, you agree to our Terms of Service and Privacy Policy.

One email per release.

What changed in the plugin, the CLI and the dashboard, with the steps to update. Nothing else.

Every email has a one-click unsubscribe link.

Questions we get asked.

Your fix is merged.

Upload the bundle, set the rollout to 5%, and the first devices pick it up on their next check.