[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.

[Pachebel]

@mvanbeusekom, I looked into this and would be happy to work on it (already started xD).

Root cause is in permission_handler_apple/ios/permission_handler_apple/Package.swift.
Besides the hardcoded ios/Runner/Info.plist path, I found two related problems in findInfoPlist():

• The condition requires pubspec.yaml and a loadable plist in the same iteration, so when the plist is missing the walk-up doesn't stop at the app root — in a monorepo it can keep going and pick up a different app's Info.plist.
• It returns [:] silently, so every PERMISSION_* macro ends up as 0 with no build warning.

That's likely why #1544 was reported without a clear repro.

Worth noting the runtime symptom is worse than "permission denied": with the macro at 0 the strategies compile to an empty @implementation, but PermissionManager still returns them and calls checkPermissionStatus:, so a flavored app crashes with an unrecognized selector rather than returning a status.

One design question before I write anything: since the SwiftPM manifest is evaluated once and has no knowledge of the build configuration, merging the keys of all candidate plists is the only thing that works automatically, but it over-enables (a prod build would compile in dev's camera code, risking ITMS-90683).

Would you accept an opt-in config file declaring the plist per flavor, with a strict mode that fails the build when the active flavor can't be determined?

Happy to split it: a first PR for plist discovery only, and a separate one for the per-flavor mechanism.

[mvanbeusekom]

Hi @Pachebel,

Thank you for looking in to this, really appreciate it.

Your suggestions sound great. I don't have any objections against explicit configuration. I do prefer your idea of splitting up in two PRs (releases) where the first PR fixes the plist discovery and a second containing the opt-in logic per flavor.

Please let me know if you require more information or assistance.