Channels & releases¶

Builds are artifacts. Channels and releases are how you decide which artifact your testers actually get.

The model¶

A build is one uploaded artifact with its metadata: build number, version name, platform, release notes, checksum.
A channel is a named distribution stream inside a project: Internal, Beta, Production, whatever suits you.
A release is a build published into a channel. Testers subscribe to the channel, not to individual builds, so publishing a new release reaches everyone on that channel.

A channel holds a sequence of releases and, per platform, one of them is the current release: the one a tester is offered and the one the in-app updates SDK reports.

Creating a channel¶

A channel carries a name, an optional description, and three switches:

Auto-distribute new builds to this channel. New builds in the project are published into the channel automatically, which is convenient for a nightly Internal channel and a bad idea for Production.
Notify testers when a new release is published. Controls the "new release available" email. Individual testers can mute a channel from their own channel list, and tester groups have their own preference.
Public channel. Anyone with the install link can download the channel's current release without signing in. Tick it under Channel settings on the channel's own page and save; the Public install link then appears on that same page, with a copy field beside it. It is not shown while the channel is private, and turning the switch off revokes the link immediately. See anonymous install links.

Publishing a release¶

Pick a build, optionally override the release notes for this channel, and decide whether the release is mandatory.

Mandatory releases are surfaced to testers as required, and the in-app updates SDK reports isMandatory so your app can refuse to let the user dismiss the prompt. You can flip an existing release between mandatory and optional at any time.

Managing a live release¶

Action	What it does	Reversible?
Disable	Takes the release out of circulation without deleting it	Yes: enable it again
Enable	Puts a disabled release back into circulation	Yes
Mark mandatory / optional	Changes whether testers must install it	Yes
Roll back	Steps the channel's current release back to the previous one	The release stays visible, flagged as rolled back
Delete	Removes the release from the channel	No

Rollback is the tool for "the build we shipped this morning is bad". It changes what the channel serves without touching the build itself, so you keep the artifact and the audit trail. Disable is the tool for "nobody should get this, but I'm not ready to change what's current".

Deleting a build is a different, heavier action: it removes the artifact. See Build lifecycle & retention.

Analytics¶

Channels and releases each have an analytics view:

Channel analytics: total downloads, unique testers, distinct builds, and the first and last download timestamps.
Release analytics: the same shape scoped to one release, plus per-tester install status where the SDK or the install flow has reported it.

Analytics are for distribution reach, not product usage. AppGantry does not embed an analytics SDK in your app.

Channels and the in-app updates SDK¶

A channel is also the unit the SDK talks to. You create an SDK app on a channel, which yields:

an app key, a public identifier that is safe to ship in your binary, and
an app secret, shown once at creation, which authorizes an install to enroll.

An enrolled install exchanges the secret for a per-install update token valid for 30 days, and then polls the channel for its current release. Revoking an SDK app immediately stops every install using it from receiving updates. See SDK configuration.

Choosing a channel layout¶

A layout that works for most teams:

Channel	Auto-distribute	Notify	Public
Internal	On	Off	No
Beta	Off	On	No
Production	Off	On	Sometimes

Every build lands in Internal automatically for the team to dogfood. Promotions to Beta and Production are deliberate, notify their testers, and can be rolled back.