The Mistake That Taught Me to Use Flutter Flavors
Article Summary
Abdelrahman Khalil accidentally shipped a production app pointing to staging servers. That painful mistake led him to master Flutter Flavors—and he's breaking down exactly how to avoid the same fate.
This hands-on guide from a senior Flutter developer walks through the complete setup of environment management using Flutter Flavors. It covers the configuration needed for both Android and iOS to maintain separate dev, staging, and production builds from a single codebase.
Key Takeaways
- Manual environment switching leads to production incidents when developers forget to update URLs
- Flavors create isolated build variants with unique bundle IDs, app names, and API endpoints
- Android setup requires productFlavors in build.gradle with dimension grouping and applicationIdSuffix
- iOS configuration demands schemes, configurations, and bundle ID management through Xcode
- Separate entry points (main_staging.dart, main_prod.dart) ensure correct environment initialization at build time
Flutter Flavors transforms environment management from error-prone manual switching into a build-time guarantee, making it impossible to accidentally ship the wrong configuration.
About This Article
Developers on Abdelrahman Khalil's team manually switched API URLs between environments, and there was nothing in the build system to catch mistakes before deployment. This created real risk of production incidents.
They set up Flutter Flavors by adding productFlavors to Android's build.gradle.kts with applicationIdSuffix properties. For iOS, they created Xcode schemes and configurations. Then they built separate entry points in main_staging.dart and main_prod.dart that each initialized the right AppConfig at build time.
Environment switching became something the build system enforced rather than something developers had to remember. The wrong API endpoint couldn't accidentally ship, and the release process stayed consistent between staging and production.