OTA update targeting by attribute

Set labels in the app, release to the devices that match, and see how many you reach before you ship.

From the team behind Capawesome, trusted by 1,000+ teams

  • Bitpanda
  • BTC-ECHO
  • Clovis
  • DHBW
  • E.ON
  • EGYM
  • Eyloo
  • FARO
  • King Arthur Baking
  • Leexi
  • LLMBase
  • Logistiko
  • mobile function
  • Planfred
  • SINC
  • snapAddy
  • Tapni
  • Vattenfall
  • Vitruve
  • AppScreens
  • OpenForge
  • Summon Worlds
  • SpeedPay
  • Rechnerhaus
  • World Aquaculture Society
  • Helmholtz

How it works

Labels in the app, conditions on the release

One app, many customers. Your app says what a device is; a release says which of them it is for.

Over-the-air (OTA) update targeting in HotCodePush sends a release to the devices whose labels match its conditions. One app serves many customers, and few updates are for everyone: a fix for one tenant, a beta for a cohort. Elsewhere: a channel per group or a hand-typed device list. The app sets labels such as tenant or plan, a release names the labels it is for, each device checks them itself, and the audience preview counts the reach before you publish.

Read the targeting guide

A release dialog with the conditions "plan is enterprise" and "tenant is acme" above the devices of a channel, the ones that match filled in.

The proof

See the audience before you publish

Type the conditions and the count appears as you type, in the console's release dialog and in the CLI's dry run.

  • An exact count for every condition

  • An estimate for the rollout percentage

  • A wrong value shows as a wrong number first

The audience preview: the devices of a channel as tiles, the ones the release reaches filled in, under the rollout step and above the armed auto-pause.

The proof

Every device of one user

Set a user id as a label, and one condition reaches every device that user signs in on, phones and tablets alike.

  • One label, every device of the user

  • No device ids to collect

  • Other users see nothing new

A user-id label fanning out to three of the user's devices, each marked with the release, and a fourth device of another user left out as not targeted.

The proof

Checked on the device, not by a server

Each device checks a release's conditions itself, so the right update arrives with no server of ours deciding.

  • Every condition evaluated on the device

  • No server decides per device

  • An unknown condition means no update

A phone checking three conditions itself, the plan, the binary and the rollout bucket, and reaching the release, beside a dimmed server marked no server decides.

From the terminal

Count the reach, then release to it

Preview how many devices a condition reaches, release to the match, and confirm what one device will get.

zsh — my-app

$ npx hotcodepush audience get --channel production --attribute plan=pro
412 devices on production match plan=pro
OS DEVICES
ios 268
android 144
$ npx hotcodepush release create --path dist --attribute plan=pro --binary ">=2.3.0"
✓ reach — 398 of 412 devices, the rest skip with a typed reason
✓ created release #43 on production
$ npx hotcodepush device probe --device 6b1e9d37-2f5c-4a80-9c46-d8e3a1f7b259
Channel production, ios
Outcome available, release #43
RELEASE ROLLOUT CONDITIONS VERDICT
#43 100% attribute pass, binary pass eligible

Guarantees

What holds for every condition

Reach you can count, and values shown to you and hashed where the index is public.

reach before you publish
Exact
values in the public index
Hashed
values in your console
Real
or a whole cohort
1 device

Figures as of November 1, 2026.

The field

How the field does it

Who an update reaches and what you see before publishing, from the vendors' own documentation.

Feature HotCodePush Capgo
Who a release reaches The devices in a channel whose labels match the conditions of the release Every device on a channel; one device is moved by a channel override in the console or the API
A group picks its own release The app sets a label; a release names the labels it is for The app moves the device to a channel that allows self-assignment
Audience preview before publishing A count of the devices a release reaches, exact per condition Not in the Capgo documentation as of 2026-10-26

Last verified 2026-10-26.

More features

Three more things every release gets

Each feature has its own page: the mechanism, the specifics, the field compared and the questions teams ask.

  • Adoption per release, every failed and skipped update with its reason, and monthly active devices that match the invoice, read in the console, the CLI or the API.

    See the feature
  • Start a release small, let it widen on the schedule you set, and have it pause itself the moment failures rise, with one command back to the release before.

    See the feature
  • Code signing with a key only you hold, verification on the device before anything is applied, and delivery with no server of ours on the path.

    See the feature

FAQ

Targeting questions

Anything your app knows about the device that is not personal data: a tenant, a plan, a region, a test group, an opaque user id. You pick the names and the values, and the app sets them when it learns them, such as after sign-in. Set labels in the app
With one condition on a user id. Set the id as a label in the app, and the release reaches every device that user signs in on. For a handful of known devices, a device list works too. Target one user or device
Check the audience preview first. The console shows the count as you type the conditions, and the CLI's dry run prints the same number without uploading anything. A wrong value shows up as a wrong number before anything ships. See what the fleet runs
Yes, for environments and for content one group must never see. Production, staging and a beta channel stay apart, and conditions pick devices inside one of them. A tenant that must not fetch another tenant's files gets a channel of its own. Set up environments and tenants
From your app. It sets them through the SDK where it learns them, after sign-in for a user id or a plan, and the device checks every condition against them itself. HotCodePush never assigns a label. Read the targeting guide
Nothing new. It keeps the release it runs and records a skip with the reason device not targeted, which the console, the probe and the result in the app all show the same way. Results and reasons

Release to the devices you mean, and see how many first.

Free for 1,000 MAU. No credit card.