Meet CascadeCI: Mobile CI/CD and Release Management Made Simple

CascadeCI is a mobile release dashboard with a command-line setup workflow. Your configured builds run in GitHub Actions; CascadeCI brings release history, execution failures and supported Google Play and App Store Connect status into one place.

CascadeCI supports Flutter and React Native for the supported Android and iOS project shapes. Flutter uses dart pub global activate cascade_cli; React Native uses npm install -g cascadeci-cli. Follow the Flutter setup guide or React Native setup guide for current requirements. Native Swift and Kotlin integrations remain upcoming.

You push a change. The build succeeds. But where is the release now: uploaded, processing, available to testers or publicly available? Those are different outcomes. CascadeCI helps you follow the evidence behind each one.

What CascadeCI does#

CascadeCI connects three parts of a mobile release:

• Setup: the CLI links a project, creates the required project files and configures credentials for your chosen destinations.
• Execution: GitHub Actions performs configured build, signing, upload and submission steps.
• Visibility: the Release Control Center organizes apps, release attempts, linked executions, structured failures and available store lifecycle observations.

Google Play and App Store Connect remain the authorities for their processing, review and availability states. A completed workflow does not, by itself, establish that an app is live.

For example, an Android build may already be available to a testing group while an iOS build is still processing. Keeping those outcomes separate makes the dashboard useful when both platforms move at different speeds.

Choose the destinations you need#

Start by deciding who needs the build. You can enable the relevant delivery lanes instead of setting up every destination at once.

Depending on configuration, those paths include APK or artifact delivery, email delivery, Google Play testing or production tracks, TestFlight and App Store submission. For a Google Play closed testing lane, use the actual track configured for your application; an arbitrary track name does not create the required store setup.

TestFlight availability is different from App Store publication. Likewise, uploading to a Play testing track is different from making a production release available to all users.

Enabled lanes gate execution. A commit-message tag selects a documented lane; it cannot force a disabled lane to run. The untagged path defaults to an APK build, with email delivery when its lane is enabled. Read the command and configuration reference before choosing a trigger.

Your first Flutter setup, step by step#

Use the live Flutter guide for requirements, installation details and the exact generated files. The practical sequence is:

1. Create a CascadeCI account and complete email verification.
2. Install the CLI from its official pub.dev package. Check the package's current Dart and GitHub CLI requirements.
3. Run cascade login, then run cascade init from your Flutter project root.
4. Review the generated guide and fill the local cascade.secrets.env file with the values required for your intended lanes.
5. Run cascade match to configure supplied credentials.
6. Enable the destinations you want in the dashboard.
7. Run cascade doctor and resolve required setup errors.
8. Commit the generated project and workflow files specified by the guide. Never commit the local secrets file.
9. Push to the repository's bound default branch using the documented trigger, then follow the release in the dashboard.

The core commands are:

cascade login
cascade init
# Fill the local secrets file using the generated guide.
cascade match
# Enable the intended lanes in the dashboard before the final check.
cascade doctor

These commands do not replace provider account setup, signing requirements or the store's testing and review rules. Start with one testing destination so you can understand the complete path before expanding it.

What cascade match configures#

Release execution and store-status observation use credentials for different purposes.

cascade match uploads supplied release and signing values to their expected GitHub secret slots. When direct status access is supported, it also submits the relevant store API credentials to CascadeCI's authenticated credential service for encrypted storage and validation. Signing material is not needed simply to read store status.

GitHub continues to run your build and release workflows. A separate GitHub authorization connection is not required specifically for direct provider status reads.

Supplying a credential file does not automatically make a store status connection valid. Validation needs the exact recorded release target. If the first successful store upload has not been recorded yet, setup can remain pending. Complete that upload and rerun cascade match so validation can use the recorded target.

If validation fails, use the reported setup state to investigate provider permissions, app identifiers and the release target. A pending or failed setup state is not evidence that your app has become available in the store.

What cascade doctor checks#

cascade doctor checks the project's expected setup, including login, generated files, workflow configuration and requirements for enabled lanes. It also reports supported store-status setup without showing stored credential values.

Run it after selecting your lanes, and again when you change the release configuration. If it reports a required missing secret or workflow problem, fix that specific issue before starting another release.

The generated workflow has integrity requirements. If it was edited and a tampering error appears, follow the guide's recovery instructions rather than assuming an arbitrary workflow edit is supported.

Read release status without confusing the stages#

Use the Release Control Center to answer four separate questions:

1. Which app, version and build does this record describe?
2. What happened in its workflow execution?
3. Did the selected upload or delivery stage complete?
4. What does the latest supported store observation say?

An upload can succeed while processing continues. Review can finish before public availability. A failed earlier attempt can coexist with a newer successful attempt. Release history keeps those distinctions visible.

When something fails, open the associated execution and use the diagnostic context to identify the stage that needs attention. Do not infer the cause from a single overall badge.

How the 20-minute refresh policy works#

Normal store-status checks use a shared, server-controlled 20-minute eligibility policy. Dashboard access and normal manual refresh follow the same gate, and active checks are deduplicated.

This does not promise a background check every 20 minutes or guarantee that every provider change appears exactly 20 minutes later. Eligibility, queue processing, provider responses and temporary access failures can affect the result.

When a check fails, the last known observation remains useful, but its age matters. Read the timestamp and failure context instead of treating old information as a new confirmation.

Credentials and costs#

Configured GitHub Secrets support workflow execution. CascadeCI's separate ingestion and worker services handle encrypted status credentials; the web dashboard does not receive the credential decryption key or provide a way to redisplay stored values.

These are handling boundaries, not a claim that any system is risk-free. Review the security page and privacy page before supplying credentials.

CascadeCI is currently free to use, as described on the pricing page. External services may still charge for runner usage, Apple membership, storage or other integrations. Check those providers' terms for your own project.

Start with one app and one testing lane#

The most useful first milestone is a traceable release: a configured project, a clean setup check, a completed execution and a clear destination outcome.

Follow the setup guide, keep the documentation nearby, and use the dashboard to follow what happens after the build finishes.