Five switches. Two app stores. How I built Fud AI’s release pipeline

Building the app was only half the release. I still had store listings, screenshots, notes, and subscriptions to deal with.

For Fud AI, I moved those steps into GitHub Actions. Five switches decide what runs; a version tag starts the workflow.

The controls

The diagram shows the five repository variables. Listing updates and screenshots can run independently of production rollout or review submission.

Unset means off. Enabled switches stay enabled for future releases. On iOS, listing updates include What’s New; Play release notes require a binary upload.

Android: tag, build, then decide whether to publish

An android-v* tag runs checks, builds signed AAB/APK files, adds signatures and provenance, and creates a GitHub Release.

Production rollout is optional. When enabled, it uploads the AAB to Play’s production track with status completed, subject to Google’s processing and review. There’s no testing-track selector.

I still increment versionCode before tagging.

iOS: two systems share the release

An ios-v* tag starts two paths: Xcode Cloud archives and uploads the binary; GitHub Actions handles checks, metadata, review submission, and the GitHub Release.

The matching App Store version must already exist, with the right build selected. Actions doesn’t yet wait for Xcode Cloud or select that build. I’m planning that handoff for the next update.

Submitting still means waiting for Apple’s review.

Subscriptions are part of the release

The submission script includes eligible subscriptions and in-app purchases from the repository’s catalog. Subscriptions use their subscription-version relationship.

If a required product can’t be attached, app submission stops. Retries reuse the draft and skip products already added.

Keep the content alongside the code

Listing copy lives in APPSTORE.md and PLAYSTORE.md. Notes and screenshots also come from the repo. A dry run prepares the files and validates the catalog before any store API calls.

Credentials stay in GitHub Secrets; switches are repository variables. RevenueCat catalog writes aren’t implemented yet, so enabling that sync fails explicitly.

Where it stands

Currently, iOS listing updates and review submission are enabled. Android rollout, screenshots, and Play release notes are off.

The next step is the iOS build handoff. If you’re building something similar, start with a dry run, then enable store actions as each release is ready.

Which part of your mobile release still makes you open the store console?

Implementation: https://github.com/apoorvdarshan/fud-ai/tree/main/store

Originally published on X.