Get a Flutter App to Production

Get a Flutter App to Production

Posted on by Toma Velev

Taking a Flutter app to production involves several preparatory technical tasks to ensure your app is reliable, performant, and ready for release. Here’s a checklist of key steps across multiple areas—code, build, testing, configuration, and deployment:

✅ 1. Final Code Clean-Up

  • Remove print/debug statements.
  • Use proper logging (dart:developer or logger package).
  • Refactor spaghetti or duplicated code.
  • Ensure proper state management (Provider, Riverpod, BLoC, etc.).

✅ 2. Linting & Static Analysis

  • Enable and fix issues from:
    • flutter analyze
    • Dart’s linter (analysis_options.yaml)
  • Optionally, use SonarQube or dart_code_metrics for deeper analysis.

✅ 3. Testing

  • Unit tests for logic-heavy parts.
  • Widget tests for UI.
  • Integration tests for user flows. 
    flutter test
flutter drive --target=test_driver/app.dart

✅ 4. Performance Optimization

  • Profile the app with flutter run --profile.
  • Analyze layout rendering with the Flutter DevTools.
  • Optimize large images (prefer webp over png/jpeg).
  • Lazy-load heavy data or UI elements.

✅ 5. App Size Reduction

  • Use flutter build apk --split-per-abi or equivalent for iOS.
  • Minimize dependencies (remove unused packages).
  • Use deferred/lazy imports for large screens/modules.

✅ 6. Security & Obfuscation

  • Use Flutter’s obfuscation: 
    flutter build apk --obfuscate --split-debug-info=/<dir>
  • Store sensitive keys securely (e.g., Firebase config, API tokens).
    • Use flutter_secure_storage or platform-specific keychains.

✅ 7. Versioning & Build Number

  • Set version: x.y.z+buildNumber in pubspec.yaml.
  • Automate this using CI/CD tools or scripts.

✅ 8. Configuration per Environment

  • Use flavors for dev/staging/prod. 
    flutter build apk --flavor prod -t lib/main_prod.dart
  • Store environment configs separately (.env + flutter_dotenv).

✅ 9. Firebase / Crashlytics / Analytics (Optional but Recommended)

  • Set up Firebase if using:
    • Crashlytics
    • Analytics
    • Push notifications
    • Remote config

✅ 10. CI/CD Pipeline

  • Automate:
    • Code checks (lint/test)
    • Builds (using GitHub Actions, Bitrise, Codemagic, etc.)
    • Deployment to Play Store / App Store / Firebase App Distribution

✅ 11. Android/iOS Specific Steps

Android:

  • Configure android/app/build.gradle with proper minSdk, targetSdk, and signing configs.
  • Generate release key: keytool, and store it securely.

iOS:

  • Create a proper App Store provisioning profile and certificate.
  • Configure Runner.xcodeproj with correct bundle ID, version, and signing.
  • Test on real devices.

✅ 12. Store Assets & Metadata

  • App icon: flutter_launcher_icons
  • Splash screen: flutter_native_splash
  • Store listing: Title, description, screenshots, privacy policy

✅ 13. Build for Production

flutter build apk --release
flutter build ios --release
flutter build web --release

✅ 14. Upload to Store

  • Google Play Console or Apple App Store Connect.
  • Test on internal track/TestFlight before public rollout.

Would you like a sample CI/CD pipeline or flavor setup as a starting point?

Staged Rollouts?

Yes — staged rollouts (aka phased releases) help you deploy your Flutter app to a limited audience before reaching all users. Both Google Play and Apple App Store support this, but each has its own requirements and process.

✅ Google Play Store – Staged Rollout Requirements

🔧 Preconditions

  • Your app must be in production track (not just internal/open testing).
  • Your release must be signed and uploaded as a production build (APK or AAB).
  • The app must pass all checks (policy, security, etc.).

🧩 Steps to Stage a Rollout

  1. Go to Google Play Console → “Production” → “Releases.”
  2. Create a new release (or edit an existing one).
  3. Click “Roll out to production”.
  4. Choose a rollout percentage (e.g. 5%, 10%, etc.).
  5. Monitor feedback and crash reports (via Play Console or Firebase Crashlytics).
  6. Increase rollout gradually, or halt if issues are found.

🛡️ Best Practices

  • Use Crashlytics + analytics to monitor small group impact.
  • Tag release versions clearly (e.g., 1.2.3-prod).
  • Have a rollback plan or prepare a hotfix branch in CI/CD.

✅ Apple App Store – Phased Release Requirements

🔧 Preconditions

  • App must be approved by App Review.
  • Must be a new app version, not the first submission.

🧩 Steps to Enable Phased Release

  1. Go to App Store Connect → “My Apps” → Your App → “Versions”.
  2. After approval, under “Release Options”, select:

    “Release manually” → enable Phased Release.

  3. Apple will automatically release the app over 7 days:
    • Day 1: 1%
    • Day 2: 2%
    • Day 3: 5%
    • Day 4: 10%
    • Day 5: 20%
    • Day 6: 50%
    • Day 7: 100%
  4. You can pause, resume, or cancel the rollout.

🛡️ Best Practices

  • Test on TestFlight with target devices first.
  • Ensure backend compatibility with both old and new versions.
  • Communicate changes in the release notes to users.

Optional (Shared Across Platforms)

📋 You Should Also:

  • Tag release in Git (v1.0.0-prod)
  • Keep detailed changelogs
  • Have feature flags to disable risky features remotely
  • Use backend version checks to force updates if needed

Would you like a sample staged rollout checklist or GitHub Actions template for automating this?