How would you manage different backend environments in a Flutter project?
Tests Flutter build flavors and compile-time config injection. A strong answer uses dart-define or flavor-specific entry points plus an EnvironmentConfig abstraction. A red flag is manually swapping hard-coded base URLs before each build.
WHAT THIS TESTS: This question evaluates whether you know how to isolate environment-specific variables from source code in Flutter. Interviewers want to see that you understand compile-time versus runtime configuration, can use platform build systems, and will prevent human error during releases.
A GOOD ANSWER COVERS: First, the concept of Flutter flavors or dart-define. Flavors let you create separate main_dev.dart, main_staging.dart, and main_prod.dart entry points that initialize an environment-specific config object before runApp. Second, a centralized configuration abstraction such as an EnvironmentConfig class or a generated constants file that holds base URLs, API keys, and feature flags. Third, build-time injection via dart-define arguments or flavor-specific Gradle and Xcode schemes so values are baked in at compile time rather than fetched later. Fourth, CI integration so the pipeline selects the correct flavor automatically and no engineer touches code to switch environments.
COMMON WRONG ANSWERS: Hard-coding the production URL in a constants file and asking developers to comment it out or swap strings by hand before building. Using a runtime dropdown inside the app to select the backend because that increases binary size and risks exposing internal endpoints to end users. Relying on conditional imports without explaining how the build system knows which import to resolve. Storing secrets directly in dart-define strings passed on the command line without mentioning that they still appear in the compiled binary and should be handled with care.
LIKELY FOLLOW-UPS: How would you handle secrets like API keys if dart-define exposes them in the binary? What if you need per-environment Firebase projects or Google Maps API keys on Android and iOS? How do you keep environment configuration out of widget tests? Would you use code generation or a package like envied to encrypt values, and what are the tradeoffs?
ONE CONCRETE EXAMPLE: Suppose your production base URL is https://api.example.com and staging is https://staging.api.example.com. You create lib/config/environment_config.dart with a class that has a final String baseUrl and a const constructor. In lib/main_prod.dart you call runApp with EnvironmentConfig(baseUrl: const String.fromEnvironment('BASE_URL', defaultValue: 'https://api.example.com')). Your Android build.gradle reads the flavor dimension and passes the matching dart-define, while your CI script runs flutter build apk --flavor production --dart-define=BASE_URL=https://api.example.com. Developers never edit source to switch targets.
Read the original → docs.flutter.dev
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.