What this prompt does
This prompt sets up a complete mobile CI/CD pipeline for your [platform] app using Fastlane and [ci_provider]. It creates a Fastfile with your [lanes], code signing via [signing_approach], environment management for dev/staging/production, automated version bumping ([versioning_strategy]), beta distribution through [beta_channel], automated App Store and Play Store submission, screenshot automation for [screenshot_devices], changelog generation from git commits, Slack/Teams build notifications, and a rollback procedure. It includes match setup for iOS certificates, supply configuration for the Play Store, and secrets management with [secrets_manager].
The structure works because manual mobile releases are where mistakes hide. Code signing with match and automated version bumps remove the two steps people most often get wrong under release pressure, and a defined rollback lane means the time to plan for a bad build is before you ship one — not during the incident. Generating the changelog from commits and notifying a channel keeps the whole team aware of what shipped.
When to use it
- You're releasing a
[platform]app manually and want the whole path automated. - Code signing keeps breaking and you want match to manage certificates consistently.
- You need consistent beta distribution through
[beta_channel]before store releases. - You want automated version bumps and changelogs instead of hand-editing them.
- You're setting up store submission and want it scripted with supply and Fastlane.
- You need a rollback procedure ready before a bad build forces you to improvise one.
Example output
Expect a Fastfile defining your [lanes] (test, beta, release, screenshots), match configuration for iOS certificates, supply setup for Play Store uploads, environment configs, version-bump logic following [versioning_strategy], beta distribution to [beta_channel], screenshot automation for [screenshot_devices], commit-based changelog generation, notification hooks, and a rollback lane. Secrets are wired through [secrets_manager] rather than committed.
Pro tips
- Keep certificates in match with a private git repo for
[signing_approach]; shared, reproducible signing is what ends "works on my machine" release failures. - Define
[lanes]for the real stages you ship — test, beta, release, screenshots — so each step is a single command anyone on the team can run. - Automate
[versioning_strategy](semantic version with auto-incremented build number) so two people never collide on a manual bump under pressure. - Store every credential in
[secrets_manager], never in the repo; leaked signing keys and API tokens are expensive mistakes. - Build the rollback lane now and test it, because the moment you need it is the worst moment to write it.
- Limit
[screenshot_devices]to the few sizes the stores actually require, since screenshot automation is slow and each extra device multiplies run time.
