> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stackshift.cloud/llms.txt
> Use this file to discover all available pages before exploring further.

# Distribute builds

> Upload Android and iOS builds, promote them through channels, and share them with testers through hosted install pages.

<Tip>
  **Live.** This area is documented as current, user-reliable behavior.
</Tip>

## Goal

Get a build into testers' hands with the right access controls, and promote it safely toward stable.

## Prerequisites

* A mobile app created in the Mobile workspace

## Workflow

<Steps>
  <Step>
    Create an app, then upload an APK, AAB, or IPA on the Releases tab. Uploads are virus-scanned before they can be shared.
  </Step>

  <Step>
    Promote a release through the internal, beta, and stable channels; each platform-channel pair pins one current release.
  </Step>

  <Step>
    Add testers and tester groups, then create share links: public, secret, password-protected, or invited-testers-only, with optional expiry and download limits.
  </Step>

  <Step>
    Send testers the hosted install page link (or its QR code); Android installs directly, iOS shows guidance for TestFlight or ad-hoc distribution.
  </Step>
</Steps>

## Channels and rollback

* internal, beta, and stable channels per platform, with one current release each.
* Roll back restores the previously pinned release; unpin empties the channel.
* Staged rollouts expose a new release to a percentage of installs before full promotion.

## Share links

* public: anyone with the link (Android only).
* secret: an unguessable token you can revoke or rotate at any time.
* password: the page asks for a password before allowing the download.
* testers: the page asks for an email and only recognized testers get the file.
* Every link supports expiry dates and maximum download counts, and page views and downloads are tracked per release.

## Governance

Roles (owner, release manager, QA reviewer, developer) gate who can upload, promote, approve, and configure. Release policies can require approvals and gates before a release reaches protected channels, and every action lands in the audit log. Webhooks announce publishes, promotions, and rollbacks to your own systems.

## Expected result

<Check>
  Testers install builds from a link you control, and rolling back a bad release is one click on the Channels tab.
</Check>

## Common failures

<Warning>
  * A release cannot be promoted or shared: the virus scan is still pending or flagged the file.
  * An invited tester cannot download: their email must be on the tester list attached to the link.
  * Expecting a public install button for iOS: Apple does not allow public sideloading, so iOS pages show truthful TestFlight/ad-hoc guidance instead.
</Warning>