Skip to content
CascadeCASCADE
Get started

Documentation

Reference

Concepts, tags, secrets, and FAQ. For a linear setup path, see How to use.

Flutter — Android and iOS delivery via the Cascade CLI and generated Cascade workflow.

Overview

Using the Release Control Center

Open the dashboard to scan all Apps, with independent Android and iOS status. Total Apps, Live, In Review and Needs Attention cover the whole authorized workspace, including Apps on later pages. Use Previous and Next to browse 25 Apps at a time.

Open an App to see attention items, explicit lifecycle evidence, the recorded timeline and paginated release history. Build / Release Action and Status Refresh Action link to separate exact GitHub runs when recorded. App settings now contains delivery lane controls.

The latest reported status appears first. Visible current Android and iOS releases are checked independently: automatic refresh for the exact current release can start when the last successful check is at least 20 minutes old or missing. Reloads inside that window reuse the latest status, and active requests are reused. Historical releases and manual-only Apps do not queue automatically. At most two requests run together. The page briefly checks the latest status while refresh is active, then stops. Use Refresh view if a workflow takes longer. Freshness is evidence age, not live streaming; Built or Uploaded alone does not establish store availability.

Status shows Updated just now or Updated 8m ago, Checking status… while queued, and Refreshing… while running. Failed refreshes preserve the successful-check time; failure backoff and provider/GitHub rate limits may delay another attempt. Explicit Refresh Status obeys the same 20-minute successful-check gate and retry limits. Run cascade match to configure store-status access ; no GitHub App authorization is needed for that setup. Existing Apps can retain their compatible workflow status path. For manual dispatch, expand the workflow instructions returned after a queued manual refresh and run the displayed command from that App’s repository.

Needs Attention uses recorded failure or review information. Detailed reviewer feedback is not exposed by the approved Google or Apple API reads. Open Google Play Console or App Store Connect for the exact review. Cascade does not invent rejection feedback. Workflow readiness issues may require rerunning cascade init and committing the generated workflows to the default branch.

When a current execution fails, the platform shows Build Failed, Signing Failed, Upload Failed or Submission Failed when the recorded operation supports that reason. Read the safe explanation and suggested action, then use Open GitHub Actions for the exact run and full logs. Failed attempts remain in release history after a successful retry. Processing Failed, Rejected and Status Refresh Failed describe separate store or refresh outcomes. Bootstrap, cancelled or interrupted executions may show only Execution failed.

Cascade reads store status using credentials configured by cascade match. Release and signing credentials stay in GitHub Secrets.

Artifacts show only the latest retained APK until expiry. Readiness describes configuration expected by enabled lanes and recorded successful builds; it does not verify credential validity.

cascade match configures release credentials and automatic store-status access . Status setup does not require a GitHub App authorization. GitHub CLI access is still needed to upload release secrets. Once credentials are validated, Cascade reads store status directly.

Cascade is a control plane for app release delivery. You enable lanes in App settings; CI runs a Cascade workflow that asks Cascade for a job plan, then builds or uploads accordingly and emails status.

This documentation set covers Flutter (Android delivery). iOS delivery requires Apple API credentials, a signing repository and your team ID. The current product model, different project tooling.

Store releases automatically resolve a safe app version and build number before building. TestFlight reuses a newer unreleased train and increments its build; otherwise a new train gets a patch bump. Google version codes increase across the uploaded inventory. Selected platforms are independent; selecting both store deliveries coordinates one semantic version. Non-store builds keep their local version. Existing Google releases work with usable semantic names supplied by Google, including default names; no Cascade-specific naming is required. Ambiguous names, locked App Store reviews and incomplete provider reads fail before upload.

  1. Create a Cascade account (email OTP).
  2. Install the CLI, run cascade login and cascade init.
  3. Get store secrets (see Secrets), put them in cascade.secrets.env, run cascade match, enable delivery lanes in App settings.
  4. Run cascade doctor, then ship with a commit tag or the default APK path (no tag).

Step-by-step: Flutter guide.

CLI and release reference · Cascade