How do you handle platform-specific configurations per flavor on Android and iOS?
Tests if you know flavors delegate icons and titles to native tooling. On Android, use productFlavors in build.gradle with source sets or placeholders; on iOS, use Xcode build configurations with Info.plist values or asset catalogs.
What's really being asked
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.
The full answer
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.
The mistakes people make
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.
What usually comes next
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.
A 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.
Interview question
When setting distinct icons and bundle names per Flutter flavor on Android and iOS, where does the essential configuration belong?
- a.In a third-party pub package that abstracts all platform-specific setup without native changes.
- b.In Dart code, using runtime conditionals to swap assets and titles after app launch.
- c.In the native toolchains, using Gradle source sets and Xcode build configurations with asset catalogs.Correct
- d.In the Flutter framework layer, via pubspec.yaml entries and environment variables passed to main.dart.
Why? this is the answer
Flavor-specific assets and identifiers are resolved at build time by Gradle and Xcode, so you must configure native source sets and build configurations. Attempting to swap them from Dart at runtime is a common misconception because app stores require these values to be baked into the native package before distribution.
Just read this? Test yourself on what you have been reading.
Read the original → docs.flutter.dev
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on flutter — each one lists the topics its interview covers.
See open roles