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.

1. Choose CI/CD platform — use the decision tree below
2. Invoke app-gtm-release:cicd-setup to configure the pipeline
3. Set up code signing:
   • Android: generate upload keystore, configure Gradle signing
   • iOS: create distribution certificate + provisioning profile in Apple Developer portal
4. Configure environment injection — template-based secrets (never commit real values)
5. 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.

1. Invoke app-gtm-release:store-setup for guided setup
2. 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
3. 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.

1. Invoke app-gtm-release:testing-tracks for the full testing progression
2. 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)
3. Pre-launch report (Google Play): automatically generated on closed/open track upload — check for crashes, accessibility, security
4. Real device testing (optional but recommended): BrowserStack or Sauce Labs for device matrix coverage
5. Closed/external testing:
   • Google Play: closed testing track with email lists
   • TestFlight: external testing (up to 10,000 testers, first build requires App Review)
6. Collect feedback, fix critical issues, rebuild

Phase 4: Launch (Hours 18-24)

Goal: Production release live on both stores.

1. Production build:
   • Enable obfuscation: --obfuscate --split-debug-info=build/symbols
   • Upload Sentry debug symbols: sentry-cli upload-dif build/symbols
2. Submit to Google Play:
   • Upload AAB to production track
   • Staged rollout recommended (start at 20%)
   • Use managed publishing to control exact go-live moment
3. 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
4. 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:

Coordinating Skills

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

1. app-gtm-release:pre-launch-checklist — verify readiness (flavors, error monitoring, force update, security)
2. app-gtm-release:cicd-setup — pipeline and signing
3. app-gtm-release:app-security — Firebase App Check + hardening
4. app-gtm-release:store-setup — console/connect configuration
5. app-gtm-release:store-listing — assets and descriptions
6. app-gtm-release:monetization — RevenueCat / Lemon Squeezy (if applicable)
7. app-gtm-release:testing-tracks — progressive testing
8. app-gtm-release:code-push — Shorebird setup for post-launch patching
9. 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