[Bug] Automatic permission detection doesn't work in apps using flavors

[mvanbeusekom]

Versions: Flutter 3.44.4, permission_handler_apple 9.4.10

The automatic detection of permissions added with the support for Swift Package Manager doesn't work for applications using multiple Info.plist files separated by build configurations (e.g., Info-Debug.plist and Info-Release.plist) instead of the default Info.plist.

It seems the plugin fails to detect the required permission keys because it only searches for the hardcoded ios/Runner/Info.plist path during the build time.

NOTE: originally reported by @tazan83 as part of issue #1544.

[mvanbeusekom]

@tazan83, is it possible to provide some more information on the configuration used in the app that experiences this problem?

Is it configured according to the Flutter recommended set up as described in the article Set up Flutter flavors for iOS and macOS or a more custom implementation?

This information might help us to determine what would be the most appropriate solution to fix this issue. Some directions I am thinking about is:

1. Is it possible to determine which filename Xcode expects for the Info.plist. If Xcode broadcasts this in someway during the pre-compilation process this would be the preferred solution as we don't rely on our own logic on constructing the correct filename.
2. Try to construct the expected filename for the Info.plist based on the Xcode build configuration (with a fallback to Info.plist). This relies on being able to detect the build configuration during the pre-compilation step and has a potentially change to fail if the info.plist file is named using a custom set up.
3. Try to construct the expected filename based on the --flavor parameter passed in with the flutter build or flutter run command. This will only work for applications using the Flutter recommended set up, so applications using a custom solution will fail.
4. Provide an additional environment variable that will be used to override the filename used to lookup the Info.plist configuration. Although not ideal, this can be added as extra option for application that don't fit the above requirements.

@TheoGermain, @olekeke999, do you happen to have any insights on this issue?

[treacks5]

Confirming this affects Permission.locationWhenInUse / Permission.locationAlways too, not just the general detection.

Setup: Flutter 3.44.4, permission_handler ^12.0.3, permission_handler_apple 9.4.10. iOS project uses per-build-configuration Info.plist files (Info-Debug-dev.plist, Info-Release-prod.plist, etc. via INFOPLIST_FILE), not the default ios/Runner/Info.plist.

Symptom: Permission.locationWhenInUse.request(), called in isolation, never presents the system dialog on a fresh install — resolves immediately to permanentlyDenied, and no "Location" entry ever appears under Settings > [App] (Notifications works fine for the same app).

We confirmed the usage description keys are present in the compiled Info.plist inside the built .app, and that device-wide Location Services is enabled. We also confirmed via a verbose build that after clearing DerivedData, PERMISSION_LOCATION_WHENINUSE=1 / PERMISSION_LOCATION_ALWAYS=1 do show up in the compile flags for the SPM target — so in our case detection isn't silently failing, yet the dialog still never appears. So forcing the flag on doesn't fix it for us, which suggests there may be a separate runtime issue beyond just Info.plist auto-detection for apps with multiple/flavor Info.plist files.

As a control: pinning just permission_handler_apple back to CocoaPods (dependency_overrides: permission_handler_apple: 9.4.7 + a minimal Podfile with PERMISSION_LOCATION=1), while leaving every other plugin on SPM, makes the dialog work correctly again — same Flutter version, same device, same Info.plist. That isolates this to the SPM integration specifically.

One more data point: elsewhere in the same app, the Mapbox Maps SDK's own location component (location.updateSettings(enabled: true)) does successfully trigger the native location dialog on the SPM build. We haven't dug into their implementation, but it suggests Mapbox may be calling CLLocationManager directly rather than going through permission_handler, which could be a useful comparison point if you're looking for what a working SPM-era call path looks like.