In modern app development, managing multiple environments isn’t optional—it’s essential. Whether you’re working on a startup MVP or scaling an enterprise app, you’ll need separate environments for development, testing, staging, and production.
Flutter makes this possible with flavors—a powerful way to configure different versions of your app with unique settings, API endpoints, and branding.
In this guide, I’ll walk you through how to set up multi-flavored Flutter apps and share best practices I’ve learned from real projects.
🚀 What Are Flutter Flavors?
Flavors allow you to build different versions of your app from a single codebase. Each flavor can have:
- A unique app name & icon
- Different package identifiers (com.myapp.dev, com.myapp.prod)
- Custom API endpoints
- Distinct configurations for Firebase, analytics, or payments
This makes it easy to:
- Test without messing up production data
- Give QA teams their own build
- Release stable builds while continuing development
🛠️ Setting Up Flavors in Flutter
1. Define Flavors in Android
In android/app/build.gradle, add product flavors:
android {
...
flavorDimensions "default"
productFlavors {
dev {
applicationId "com.myapp.dev"
versionNameSuffix "-dev"
}
staging {
applicationId "com.myapp.staging"
versionNameSuffix "-staging"
}
prod {
applicationId "com.myapp.prod"
}
}
}
2. Define Flavors in iOS
In Xcode:
- Go to Runner > Info.plist
- Add new schemes (Dev, Staging, Prod)
- Update Bundle Identifiers (e.g., com.myapp.dev)
3. Create Separate Main Entry Files
Inside lib/, create:
- main_dev.dart
- main_staging.dart
- main_prod.dart
Each entry file can set different configs:
import 'app.dart';
import 'config.dart';
void main() {
Config.appFlavor = Flavor.dev;
runApp(MyApp());
}
⚙️ Managing Configurations
Define a Config class to handle environment-specific settings:
enum Flavor { dev, staging, prod }
class Config {
static late Flavor appFlavor;
static String get baseUrl {
switch (appFlavor) {
case Flavor.dev:
return "https://api.dev.myapp.com";
case Flavor.staging:
return "https://api.staging.myapp.com";
case Flavor.prod:
return "https://api.myapp.com";
}
}
}
Now your app automatically picks the right API endpoint depending on the flavor.
🤖 Automating Builds with CI/CD
Once flavors are set up, you can automate builds using GitHub Actions, Bitrise, or Codemagic.
Example (Codemagic YAML):
workflows:
dev:
environment:
flutter: stable
scripts:
- flutter build apk --flavor dev -t lib/main_dev.dart
staging:
scripts:
- flutter build ios --flavor staging -t lib/main_staging.dart
prod:
scripts:
- flutter build appbundle --flavor prod -t lib/main_prod.dart
This way, pushing to different branches can trigger automatic builds for QA, beta testing, or App Store release.
✅ Best Practices for Flavors
- Keep configs separate – Never hardcode API keys. Use .env files or secure storage.
- Use consistent naming – main_dev.dart, main_staging.dart, etc.
- Automate builds – Saves time and avoids human error.
- Use Firebase per flavor – Each environment should have its own Firebase project.
- Test thoroughly – Ensure each flavor points to the correct backend before shipping.
🎯 Conclusion
Using Flutter flavors is a game-changer for managing multiple environments in app development. With proper setup, you’ll have:
- Clean separation between dev, staging, and prod
- Faster QA cycles
- Safer deployments
If you’re building an app that scales, flavors are not just a “nice-to-have”—they’re a must-have.