Channels & Publishing¶

Understanding how release channels and publishing work.

What are Channels?¶

Channels allow you to distribute different versions of your app to different audiences.

Standard Channels¶

Channel	Purpose	Audience
`production`	Stable, tested releases	All users
`beta`	Testing versions	Early adopters, testers
`alpha` / `dev`	Experimental builds	Developers only

How Channels Work¶

Publishing: When you upload a release, you specify which channel it belongs to
Checking: Users configure their app to check a specific channel
Cascading: Beta users can "fall back" to production if no beta release exists

Publishing States¶

Each release has two important flags:

`is_published`¶

Controls whether the release is visible to end-users.

false: Draft - Stored in database but not visible to update checks
true: Live - Available for distribution

Use Cases: - Prepare a release in advance - Test the upload process without affecting users - Stage updates for coordinated rollouts

`is_latest`¶

Explicitly marks which version is the "current" recommended release.

Only one release per (app, channel, platform) can be is_latest: true
When you mark a new version as latest, the old one is automatically unmarked
If not specified, defaults to the value of auto_publish

Use Cases: - Pin a specific version as recommended (even if newer versions exist) - Roll back to an older version by changing which is marked latest

Publishing Strategies¶

Strategy 1: Auto-Publish (Simple)¶

{
  "version": "1.2.0",
  "auto_publish": true,
  "is_latest": true
}

Result: Version goes live immediately and is marked as current.

Strategy 2: Draft → Publish (Staged)¶

Step 1 - Upload as Draft:

{
  "version": "1.2.0",
  "auto_publish": false
}

Step 2 - Test internally

Step 3 - Publish manually (update the same record):

{
  "version": "1.2.0",
  "auto_publish": true,
  "is_latest": true
}

Strategy 3: Multi-Channel Rollout¶

Week 1 - Release to Beta:

{
  "version": "1.2.0",
  "channel": "beta",
  "auto_publish": true
}

Week 2 - Promote to Production:

{
  "version": "1.2.0",
  "channel": "production",
  "auto_publish": true
}

Strategy 4: Rollback¶

If version 1.2.0 has a critical bug:

Option A - Unmark it:

{
  "version": "1.2.0",
  "is_latest": false
}

Then mark the previous version:

{
  "version": "1.1.0",
  "is_latest": true
}

Option B - Unpublish it entirely:

{
  "version": "1.2.0",
  "is_published": false
}

Channel Cascading¶

When a user checks for updates on the beta channel, the API:

First looks for the latest beta release
If none exists, falls back to production
Returns the newest published release across both channels

This ensures beta users always get at least the production version.

Example: - Production: v1.1.0 (published) - Beta: v1.2.0-beta (published)

Query: ?app_id=myapp&channel=beta Result: Returns v1.2.0-beta

Query: ?app_id=myapp&channel=production Result: Returns v1.1.0

Automatic Enforcement¶

The system automatically enforces the "one latest per channel" rule:

You can have multiple releases per channel
But only ONE can be marked is_latest: true at a time
When you mark a new version as latest, the old one is automatically unmarked

This ensures your users always get the correct version when checking for updates.

Best Practices¶

Use Beta for Testing: Always test in beta before promoting to production
Version Semantically: Use semver (MAJOR.MINOR.PATCH)
Keep Drafts Short-Lived: Don't leave drafts unpublished for weeks
Document Channel Usage: Tell users what each channel means
Monitor Beta Feedback: Use beta to catch bugs before they reach everyone