| name | pre-launch-checklist |
| description | Comprehensive pre-launch checklist for Flutter apps covering code quality, environment setup, error monitoring, analytics, force updates, security, store compliance, and production readiness. Based on Andrea Bizzotto's Flutter release methodology. Use this skill when the user asks about release readiness, pre-launch review, production checklist, 'am I ready to launch', 'what am I missing before release', app review preparation, or final checks before submitting to stores. Also triggers on: 'checklist before launch', 'production readiness', 'release preparation', 'review my app before submitting'. |
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.
Implementation Options
Quick setup — flutter_flavorizr package:
dev_dependencies:
flutter_flavorizr: ^2.2.0
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.
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.
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.
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.
dependencies:
feedback: ^3.0.0
feedback_sentry: ^1.0.0
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.
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.
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.
9. UX Polish [RECOMMENDED]
10. Store Compliance [BLOCKER]
11. CI/CD Pipeline [BLOCKER]
See app-gtm-release:cicd-setup for full implementation.
Quick Reference: Must-Have for First Release
These items cannot be added retroactively or cause irreversible problems if missing:
- Flavors / environment separation
- Error monitoring (Sentry/Crashlytics)
- Force update mechanism
- Firebase App Check
- Bundle ID / package name finalized
- 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.
