How do you handle platform-specific configurations per flavor on Android and iOS?

WHAT THIS TESTS: This question checks whether you understand that Flutter flavors are a build time abstraction that delegates platform specific packaging to the native toolchains. The interviewer wants to see that you know icons, display names, bundle identifiers, and signing configs are not handled by Dart code but by Gradle and Xcode build settings.

A GOOD ANSWER COVERS: First, on Android, you define productFlavors inside the android block of the app level build.gradle file, assigning each flavor an applicationIdSuffix and a resValue for the display name. You then place flavor specific icons under directories like src dev res mipmap and src prod res mipmap so Gradle merges them during the build, or you use manifest placeholders to inject values into AndroidManifest.xml. Second, on iOS, you duplicate the Release or Debug build configuration in Xcode for each flavor, then assign each scheme a different bundle identifier, a display name via CFBundleDisplayName in an alternate Info.plist or through xcconfig files, and point to flavor specific AppIcon sets in the Asset Catalog. Third, you mention that running flutter run with the flavor flag selects the matching native configuration, but the heavy lifting happens in the native project files.

COMMON WRONG ANSWERS: A major red flag is suggesting you can swap the native app icon or bundle display name from Dart at runtime. Another is proposing a single pub package as the complete solution without acknowledging the mandatory native setup. Candidates also stumble by editing only the Flutter side and ignoring the fact that the Play Store and App Store see the native bundle identifiers and assets.

LIKELY FOLLOW-UPS: The interviewer may ask how you automate this in CI, how you handle deep linking per flavor, or how you keep the Dart code environment aware via flavor specific entry points or environment variables passed at compile time. They might also probe signing differences, such as using distinct keystores or provisioning profiles per flavor.

ONE CONCRETE EXAMPLE: Suppose you have dev and prod flavors. In Android, you create src dev and src prod directories, each containing res values strings.xml with app_name and res mipmap folders with distinct icons. In build.gradle you add productFlavors dev and prod with applicationIdSuffix .dev and .prod and set resValue string app_name accordingly. In Xcode, you create Dev and Prod build configurations, set PRODUCT_BUNDLE_IDENTIFIER and INFOPLIST_KEY_CFBundleDisplayName in Dev.xcconfig and Prod.xcconfig, and assign different AppIcon appiconsets in the Asset Catalog for each configuration. When you run flutter run with flavor dev, the native build picks the dev source set and Dev configuration automatically.