launch-plan

Launch Plan: Flutter App to Stores in 24 Hours

You are orchestrating the launch of a Flutter app to Google Play Store and Apple App Store. This skill provides the master timeline, decision framework, and coordination across all other app-gtm-release skills.

Before You Start

Verify these prerequisites with the user. Do not skip any — a missing prerequisite will block the timeline.

Accounts (must exist before Hour 0)

Google Play Console — developer account ($25 one-time). Identity verification takes 2-5 days if not already done
Apple Developer Program — enrolled ($99/year). Enrollment review takes up to 48 hours
Codemagic account (or GitHub with Actions enabled) — for CI/CD
Firebase project — for App Distribution (internal testing channel)
Sentry project — for crash reporting and symbol upload
RevenueCat account (if monetizing with subscriptions) — for in-app purchases
Shorebird account (recommended) — for over-the-air code push updates

Code Readiness

Flutter app builds successfully on both platforms (flutter build appbundle --release and flutter build ios --release --no-codesign)
Tests pass (flutter test)
App icon and splash screen configured
Version and build number set in pubspec.yaml
Bundle ID / package name finalized (cannot change after first upload)

Assets Ready

App icon (512x512 PNG, no transparency for Google Play; 1024x1024 for App Store)
Feature graphic (1024x500 for Google Play)
Screenshots: minimum 2 per device type per store
Short description (80 chars) and full description (4000 chars)
Privacy policy URL (required by both stores)

If any prerequisite is missing, help the user resolve it before starting the timeline.

24-Hour Timeline

Phase 1: Pipeline (Hours 0-6)

Goal: Automated builds that produce signed, store-ready artifacts on every push.

Choose CI/CD platform — use the decision tree below
Invoke app-gtm-release:cicd-setup to configure the pipeline
Set up code signing:
- Android: generate upload keystore, configure Gradle signing
- iOS: create distribution certificate + provisioning profile in Apple Developer portal
Configure environment injection — template-based secrets (never commit real values)
Verify: push to trigger pipeline, confirm signed artifact is produced

Quality gates to wire in:

dart format --set-exit-if-changed .
flutter analyze --fatal-infos
flutter test --coverage with configurable threshold (default 70%)

Read references/timeline-24h.md for detailed time breakdowns per step.

Phase 2: Store Setup (Hours 6-10)

Goal: Both store dashboards configured, ready to receive builds.

Invoke app-gtm-release:store-setup for guided setup
Google Play Console:
- Create app, set default language
- Complete store listing (invoke app-gtm-release:store-listing)
- Content rating questionnaire
- Pricing and distribution (countries, free/paid)
- Data safety section
App Store Connect:
- Create app record with bundle ID
- Fill app information (category, content rights, age rating)
- Prepare store listing (invoke app-gtm-release:store-listing)

Phase 3: Testing (Hours 10-18)

Goal: App validated by real users on real devices before production release.

Invoke app-gtm-release:testing-tracks for the full testing progression
Internal testing (both platforms simultaneously):
- Google Play: internal testing track (100 testers, available in seconds, no review)
- Apple TestFlight: internal testing (100 App Store Connect users, no review)
Pre-launch report (Google Play): automatically generated on closed/open track upload — check for crashes, accessibility, security
Real device testing (optional but recommended): BrowserStack or Sauce Labs for device matrix coverage
Closed/external testing:
- Google Play: closed testing track with email lists
- TestFlight: external testing (up to 10,000 testers, first build requires App Review)
Collect feedback, fix critical issues, rebuild

Phase 4: Launch (Hours 18-24)

Goal: Production release live on both stores.

Production build:
- Enable obfuscation: --obfuscate --split-debug-info=build/symbols
- Upload Sentry debug symbols: sentry-cli upload-dif build/symbols
Submit to Google Play:
- Upload AAB to production track
- Staged rollout recommended (start at 20%)
- Use managed publishing to control exact go-live moment
Submit to App Store:
- Upload IPA via Xcode, Transporter, or CI/CD
- Submit for App Review (typical: 24-48h, but often faster)
- Enable phased release if desired
Post-launch monitoring:
- Sentry crash dashboard
- Google Play pre-launch report + Android vitals
- App Store Connect crash reports
- Review store ratings/feedback within first 24h

CI/CD Platform Decision Tree

Choose based on the user's context:

Already have CI/CD with custom runners (Blacksmith, Buildjet, self-hosted)?
├── Yes → GitHub Actions + your existing runners
│         - Add Flutter via subosito/flutter-action
│         - Same dashboard, secrets, billing as your other projects
│         - Fastest builds (dedicated hardware)
│
└── No existing CI/CD?
    ├── Android only? → GitHub Actions (hosted runners)
    │                    - Free 2000 min/month (Linux)
    │                    - Sufficient for Android builds
    │
    └── Need iOS builds? → Codemagic
                           - Mac Mini M2 included
                           - Automatic iOS code signing
                           - 500 free build minutes/month

When to recommend existing runners (Blacksmith, etc.):

Already paying for custom runners for backend/web CI
Team knows GitHub Actions
Android-only for now (no macOS needed)
Want everything in one platform

When to recommend Codemagic:

Need iOS builds without managing macOS infrastructure
New project with no existing CI/CD
Want built-in code signing UI
Small team that benefits from managed Flutter tooling

When to recommend GitHub Actions (hosted):

Budget-conscious, starting from scratch
Android-only builds
Want monorepo path-filtered workflows
Cost-sensitive (GitHub free tier is generous for Linux builds)

SRE Integration Points

These reliability practices are woven into the pipeline, not bolted on after:

Practice	Where it applies	Skill reference
Coverage threshold	PR quality gate	`app-gtm-release:cicd-setup`
Sentry symbol upload	Production build step	`app-gtm-release:cicd-setup`
Pre-launch crash detection	Testing phase	`app-gtm-release:testing-tracks`
Staged rollout	Production release	This skill (Phase 4)
Structured build logging	All CI/CD steps	`app-gtm-release:cicd-setup`

Coordinating Skills

When orchestrating a full launch, invoke skills in this order:

app-gtm-release:pre-launch-checklist — verify readiness (flavors, error monitoring, force update, security)
app-gtm-release:cicd-setup — pipeline and signing
app-gtm-release:app-security — Firebase App Check + hardening
app-gtm-release:store-setup — console/connect configuration
app-gtm-release:store-listing — assets and descriptions
app-gtm-release:monetization — RevenueCat / Lemon Squeezy (if applicable)
app-gtm-release:testing-tracks — progressive testing
app-gtm-release:code-push — Shorebird setup for post-launch patching
Come back here for Phase 4 (production release)

Each skill is independently usable — a user may invoke app-gtm-release:testing-tracks alone if their pipeline is already set up.

Reference Architecture: flutter_ship_app

The flutter_ship_app by Andrea Bizzotto demonstrates many of these patterns in a real codebase:

Multi-flavor setup (dev/stg/prod) with separate Firebase projects
Sentry + Mixpanel integration per flavor
Shorebird code push configuration
Force update mechanism via force_update_helper
Environment variables via --dart-define-from-file
In-app review prompts
Drift database with web support