SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillspre-launch-checklist

pre-launch-checklist

Data & analytics

View repository

Updated 10-15 21:11

About this skill

Pre-Launch Checklist

A structured checklist to verify your Flutter app is production-ready before submitting to stores. Based on the methodology from Andrea Bizzotto's Flutter in Production course and the flutter_ship_app reference implementation, combined with practical startup shipping patterns.

How to Use This Checklist

Work through each section in order. Items marked [BLOCKER] will cause store rejection or critical production issues if skipped. Items marked [RECOMMENDED] improve quality but can ship without. Items marked [FIRST RELEASE] must be in your very first release — retrofitting later is painful or impossible.

1. Flavors & Environments [FIRST RELEASE]

Multiple build configurations prevent test data from contaminating production analytics, crash reports, and databases.

Source: flutter_ship_app uses three entry points (main_dev.dart, main_stg.dart, main_prod.dart) with separate Firebase projects per flavor.

  • [BLOCKER] Separate entry points for dev/staging/production environments
  • [BLOCKER] Different app IDs per flavor (can install all variants simultaneously)
  • [RECOMMENDED] Visual indicator for non-production builds (different icon, banner, or color)
  • [RECOMMENDED] Separate Firebase projects per flavor (analytics, crashlytics, remote config)
  • [RECOMMENDED] Environment variables via --dart-define-from-file (not hardcoded)

Implementation Options

Quick setup — flutter_flavorizr package:

# pubspec.yaml
dev_dependencies:
  flutter_flavorizr: ^2.2.0

# flavorizr.yaml
flavors:
  dev:
    app:
      name: "App Dev"
    android:
      applicationId: "com.company.app.dev"
    ios:
      bundleId: "com.company.app.dev"
  prod:
    app:
      name: "App"
    android:
      applicationId: "com.company.app"
    ios:
      bundleId: "com.company.app"

Manual setup — multiple entry points (flutter_ship_app pattern):

// lib/main_dev.dart
void main() => bootstrap(Env.dev);

// lib/main_prod.dart
void main() => bootstrap(Env.prod);

2. Error Monitoring [FIRST RELEASE]

You cannot fix bugs you do not know about. Error monitoring must be in the first release.

Source: Andrea Bizzotto recommends Sentry or Firebase Crashlytics. The flutter_ship_app uses Sentry with per-flavor DSN configuration.

  • [BLOCKER] Crash reporting SDK integrated (Sentry or Firebase Crashlytics)
  • [BLOCKER] Debug symbols uploaded for obfuscated builds (see app-gtm-release:cicd-setup)
  • [RECOMMENDED] Breadcrumbs configured (events leading to crashes)
  • [RECOMMENDED] User identification linked (to correlate crashes with users)
  • [RECOMMENDED] Performance monitoring enabled (slow frames, startup time)
  • [RECOMMENDED] Source maps / dSYMs uploaded to symbolicate stack traces

Sentry Setup (Recommended)

import 'package:sentry_flutter/sentry_flutter.dart';

Future<void> main() async {
  await SentryFlutter.init(
    (options) {
      options.dsn = const String.fromEnvironment('SENTRY_DSN');
      options.tracesSampleRate = 0.2; // 20% of transactions
      options.environment = const String.fromEnvironment('ENV_NAME');
    },
    appRunner: () => runApp(const MyApp()),
  );
}

3. Analytics [RECOMMENDED]

Track user behavior to make data-driven product decisions.

Source: flutter_ship_app integrates Mixpanel with per-flavor project tokens.

  • [RECOMMENDED] Analytics SDK integrated (Firebase Analytics, Mixpanel, or Amplitude)
  • [RECOMMENDED] Key events defined and tracked:
    • App open / session start
    • Core feature usage (the main action users take)
    • Conversion events (signup, purchase, share)
    • Error states (failed actions from user perspective)
  • [RECOMMENDED] User properties set (plan type, app version, platform)
  • [RECOMMENDED] Screen tracking (which screens get the most time)

What NOT to Track

  • Personally identifiable information (PII) without consent
  • Exact location (use approximate)
  • Keystroke-level data
  • Health/financial data (requires special compliance)

4. Force Update Mechanism [FIRST RELEASE]

If you need to force users off a broken version, this must exist from day one. You cannot retroactively add a force update prompt to an already-deployed version.

Source: Andrea Bizzotto emphasizes this as critical for the first release. flutter_ship_app uses force_update_helper package.

  • [BLOCKER] Minimum version check on app startup
  • [BLOCKER] Version comparison against remote config (Firebase Remote Config, backend API, or GitHub Gist)
  • [BLOCKER] Blocking UI when update is required (full-screen, no dismissal)
  • [RECOMMENDED] Soft update prompt for recommended (non-critical) updates
  • [RECOMMENDED] Deep link to store listing for update

Implementation Pattern

// Check on app startup
Future<void> checkForUpdate() async {
  final remoteMinVersion = await fetchMinVersion(); // From Remote Config
  final currentVersion = await PackageInfo.fromPlatform();

  if (currentVersion < remoteMinVersion) {
    showForceUpdateDialog(); // Full screen, no dismiss
  }
}

Shorebird Alternative

For Dart-only fixes, Shorebird Code Push can patch without store submission. See app-gtm-release:code-push. But force update is still needed for native changes.

5. In-App Feedback [RECOMMENDED]

Lower the barrier for users to report issues directly from the app.

Source: Andrea Bizzotto recommends the feedback package with optional Sentry integration.

  • [RECOMMENDED] Feedback mechanism accessible from settings or help menu
  • [RECOMMENDED] Screenshot annotation capability
  • [RECOMMENDED] Automatic device info attachment (model, OS, app version)
  • [RECOMMENDED] Feedback routed to issue tracker (Sentry, email, or Linear)
dependencies:
  feedback: ^3.0.0
  feedback_sentry: ^1.0.0  # Optional: routes feedback to Sentry

6. In-App Review [RECOMMENDED]

Prompt users to rate your app at moments of satisfaction.

Source: Andrea Bizzotto emphasizes timing — prompt after positive experiences, not on first launch.

  • [RECOMMENDED] in_app_review package integrated
  • [RECOMMENDED] Trigger after positive user moments (task completion, purchase, milestone)
  • [RECOMMENDED] Respect platform rate limits (iOS limits to 3 prompts/year)
  • [RECOMMENDED] Track whether prompt was shown (don't re-prompt too soon)
import 'package:in_app_review/in_app_review.dart';

Future<void> requestReview() async {
  final inAppReview = InAppReview.instance;
  if (await inAppReview.isAvailable()) {
    await inAppReview.requestReview();
  }
}

7. App Security [BLOCKER]

See app-gtm-release:app-security for detailed implementation.

  • [BLOCKER] Firebase App Check enabled (Play Integrity + App Attest)
  • [BLOCKER] No API keys or secrets hardcoded in Dart source
  • [BLOCKER] HTTPS enforced for all network calls
  • [BLOCKER] Sensitive data stored with flutter_secure_storage, not shared_preferences
  • [RECOMMENDED] Network security config (Android) and ATS (iOS) properly configured
  • [RECOMMENDED] ProGuard/R8 rules verified for release builds
  • [RECOMMENDED] Account deletion flow implemented (required by both stores)

8. Code Quality [RECOMMENDED]

Quality gates that should pass before submission.

Source: Startup shipping guide (widgettricks) recommends focusing tests on frequently breaking code rather than 100% coverage.

  • [RECOMMENDED] flutter analyze passes with no errors
  • [RECOMMENDED] dart format applied consistently
  • [RECOMMENDED] Tests cover core business logic (not necessarily 100% coverage)
  • [RECOMMENDED] Golden tests for critical UI screens (catches layout regressions)
  • [RECOMMENDED] No TODO or FIXME in production code paths
  • [RECOMMENDED] Custom lint rules for project conventions

9. UX Polish [RECOMMENDED]

  • [RECOMMENDED] Splash screen configured (native, not Flutter widget)
  • [RECOMMENDED] App icon meets both store specifications
  • [RECOMMENDED] Loading states for all async operations
  • [RECOMMENDED] Error states with retry actions (not silent failures)
  • [RECOMMENDED] Offline handling (graceful degradation or cached data)
  • [RECOMMENDED] Dark mode support (or explicit light-only design)
  • [RECOMMENDED] Responsive layout tested on smallest supported device

10. Store Compliance [BLOCKER]

  • [BLOCKER] Privacy policy URL published and accessible
  • [BLOCKER] Data safety (Google Play) / App Privacy (Apple) declarations match actual data collection
  • [BLOCKER] Content rating completed (both stores)
  • [BLOCKER] Age rating questionnaire submitted (both stores)
  • [BLOCKER] Account deletion available if users can create accounts
  • [BLOCKER] In-app purchases use StoreKit (iOS) and Play Billing (Android) for digital goods
  • [RECOMMENDED] Terms of service URL published
  • [RECOMMENDED] App review notes prepared with demo credentials

11. CI/CD Pipeline [BLOCKER]

See app-gtm-release:cicd-setup for full implementation.

  • [BLOCKER] Automated builds on push (Codemagic or GitHub Actions)
  • [BLOCKER] Code signing configured for both platforms
  • [BLOCKER] Production builds use --obfuscate --split-debug-info
  • [RECOMMENDED] PR quality gate (format + analyze + test)
  • [RECOMMENDED] Automated distribution to testing tracks
  • [RECOMMENDED] Sentry symbol upload in production pipeline

Quick Reference: Must-Have for First Release

These items cannot be added retroactively or cause irreversible problems if missing:

  1. Flavors / environment separation
  2. Error monitoring (Sentry/Crashlytics)
  3. Force update mechanism
  4. Firebase App Check
  5. Bundle ID / package name finalized
  6. Privacy policy published

Everything else can be iterated on after launch.

Methodology adapted from Andrea Bizzotto and the flutter_ship_app reference implementation. Additional patterns from the WidgetTricks startup shipping guide.