You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The problem is that SPM support was updated in permission_handler_apple 9.4.10. However, permission_handler 12.0.3 still does not reference the latest version of permission_handler_apple, so those SPM updates are not included in the current release of permission_handler.
Guys, I have fixed this "issue" removing any permissions I have made previously on Podfile. Here is some sort of step-by-step guide:
1. Upgrade Flutter Packages
To ensure you have the SPM-compatible version of the Apple permission handler, you need to upgrade your packages.
flutter pub upgrade
(Ensure permission_handler_apple updates to version 9.4.10 or higher).
2. Remove Old CocoaPods Configurations from Podfile
With SPM, Package.swift automatically detects which permissions to enable by reading the keys present in your app's ios/Runner/Info.plist. You no longer need to manually inject C macros in the Podfile.
Open ios/Podfile and remove the entire GCC_PREPROCESSOR_DEFINITIONS block associated with permissions.
Remove this block (if present):
# Remove these lines from your post_install loopconfig.build_settings['GCC_PREPROCESSOR_DEFINITIONS'] ||= ['$(inherited)','PERMISSION_CAMERA=1','PERMISSION_PHOTOS=1','PERMISSION_LOCATION=1','PERMISSION_NOTIFICATIONS=0',# ... and any other PERMISSION_ macros]
3. Opt-out of Default Permissions (Notifications / Critical Alerts)
Since PermissionGroup.notification has no required Info.plist key, it is enabled by default. If your app does not use notifications (previously PERMISSION_NOTIFICATIONS=0), you now must disable it via an environment variable before building.
After changing package versions or modifying your Podfile, Xcode needs to completely re-evaluate the dependency tree and Package.swift.
Clear your Xcode cache using:
rm -rf ~/Library/Developer/Xcode/DerivedData
5. Re-sync CocoaPods Dependencies
Because flutter pub upgrade might have updated plugins that have native iOS SDK dependencies (like Firebase), your Podfile.lock may now be out of sync. You need to delete it and force CocoaPods to fetch the updated iOS dependencies.
cd ios
rm -f Podfile.lock
pod install --repo-update
cd ..
6. Build the App
Finally, trigger a new clean build:
flutter clean
flutter build ios
Before:
permission_handler_apple still shows as not supported.
After:
permission_handler_apple is supported .
Note: this covers the standard single-Info.plist setup. Flavor-based projects are tracked separately in #1548.
Reacted by tazan83, Daniel Jimenez, uthupia, Jan Studený, quangkhaidam, Kyoka Nguyen, Eduarda Lima, Gleb Shalimov and Michael Amadheo
Reacted by quangkhaidam, Kyoka Nguyen and Eduarda Lima
I am still experiencing this issue when 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.
Could you guide me on how to properly configure the plugin when using custom Info.plist names or a multi-flavor setup?
Same issue here with a completely clean Flutter project — Podfile has zeroGCC_PREPROCESSOR_DEFINITIONS or permission-related configuration.
Environment
Flutter 3.44.2
permission_handler 12.0.3
permission_handler_apple 9.4.10
Xcode 26.0 beta / macOS 26
swift_package_manager_enabled: ios: true
Root Cause
findInfoPlist() in Package.swift returns an empty dictionary during SPM build. I verified this by adding #error "PERMISSION_PHOTOS is DISABLED" before the macro guard in PhotoPermissionStrategy.m — the build failed, confirming the macro was 0.
Neither #file nor FileManager.default.currentDirectoryPath resolves to a path that can walk up to the project root containing pubspec.yaml + ios/Runner/Info.plist. All PERMISSION_* macros default to "0", every strategy compiles as an UnknownPermissionStrategy stub, and PHPhotoLibrary.requestAuthorization is never called → iOS never registers the permission → no Photos toggle in Settings.
Scope
Not just Photos — PERMISSION_CAMERA, PERMISSION_MICROPHONE, and PERMISSION_BLUETOOTH are all affected (confirmed via #error in all three strategies).
Workaround
launchctl setenv PERMISSION_PHOTOS 1
launchctl setenv PERMISSION_CAMERA 1
launchctl setenv PERMISSION_MICROPHONE 1
launchctl setenv PERMISSION_BLUETOOTH 1
# ... etc for all needed permissions
Then restart Xcode and rebuild. Works reliably but is fragile for teams.
Would be great to have a fallback mechanism — e.g. an xcconfig-style file or an explicit plist path override — so findInfoPlist() doesn't silently fail in this scenario.
The flavors part (and a few smaller issues) should be fixed in my latest two PRs: #1553 and #1554.
Please try permission_handler_apple 9.6.0 and let me know if you find any problems.
If everything runs fine, I think this issue can be closed.
I also have concerns about relying on environment variables (PERMISSION_HANDLER_INFO_PLIST, PERMISSION_NOTIFICATIONS, PERMISSION_CRITICAL_ALERTS) to configure permissions.
Using launchctl setenv makes project-specific configuration part of the user's login session. When working on multiple Flutter projects with different permission requirements, developers have to manage these values manually and restart Xcode to pick up changes. An absolute Info.plist path is also machine-specific and cannot be shared reliably through version control.
Permission configuration should ideally live in the project, be version-controlled, and work consistently for local development and CI. Environment variables are useful as optional overrides, but they should not be required for a standard build.
Could we have a project-scoped configuration mechanism that works directly from Xcode without requiring session-wide environment variables or manual cache clearing?
Activity
jendas1 commentedon Jun 13, 2026
Facing the same issue which creates problem with the flutter workflow. Now CocoaPods are deprecated by flutter (as mentioned here: https://docs.flutter.dev/add-to-app/ios/project-setup ).
daniJimen commentedon Jun 22, 2026
The problem is that SPM support was updated in permission_handler_apple 9.4.10. However, permission_handler 12.0.3 still does not reference the latest version of permission_handler_apple, so those SPM updates are not included in the current release of permission_handler.
lyio commentedon Jun 23, 2026
@daniJimen is that a simple version bump or does the update require changes?
Pachebel commentedon Jun 23, 2026
Guys, I have fixed this "issue" removing any permissions I have made previously on Podfile. Here is some sort of step-by-step guide:
1. Upgrade Flutter Packages
To ensure you have the SPM-compatible version of the Apple permission handler, you need to upgrade your packages.
(Ensure
permission_handler_appleupdates to version9.4.10or higher).2. Remove Old CocoaPods Configurations from
PodfileWith SPM,
Package.swiftautomatically detects which permissions to enable by reading the keys present in your app'sios/Runner/Info.plist. You no longer need to manually inject C macros in thePodfile.Open
ios/Podfileand remove the entireGCC_PREPROCESSOR_DEFINITIONSblock associated with permissions.Remove this block (if present):
3. Opt-out of Default Permissions (Notifications / Critical Alerts)
Since
PermissionGroup.notificationhas no requiredInfo.plistkey, it is enabled by default. If your app does not use notifications (previouslyPERMISSION_NOTIFICATIONS=0), you now must disable it via an environment variable before building.In the terminal:
export PERMISSION_NOTIFICATIONS=0 flutter build ios4. Clear Xcode Derived Data
After changing package versions or modifying your
Podfile, Xcode needs to completely re-evaluate the dependency tree andPackage.swift.Clear your Xcode cache using:
rm -rf ~/Library/Developer/Xcode/DerivedData5. Re-sync CocoaPods Dependencies
Because
flutter pub upgrademight have updated plugins that have native iOS SDK dependencies (like Firebase), yourPodfile.lockmay now be out of sync. You need to delete it and force CocoaPods to fetch the updated iOS dependencies.6. Build the App
Finally, trigger a new clean build:
Before:
permission_handler_applestill shows as not supported.After:
permission_handler_appleis supported .Note: this covers the standard single-Info.plist setup. Flavor-based projects are tracked separately in #1548.
quangkhaidam93 commentedon Jun 28, 2026
It works perfectly. Thank a lot @Pachebel
tazan83 commentedon Jul 2, 2026
Versions: Flutter 3.44.4, permission_handler_apple 9.4.10
I am still experiencing this issue when 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.
Could you guide me on how to properly configure the plugin when using custom Info.plist names or a multi-flavor setup?
Thank you!
RockyJT215 commentedon Jul 20, 2026
Same issue here with a completely clean Flutter project — Podfile has zero
GCC_PREPROCESSOR_DEFINITIONSor permission-related configuration.Environment
swift_package_manager_enabled: ios: trueRoot Cause
findInfoPlist()inPackage.swiftreturns an empty dictionary during SPM build. I verified this by adding#error "PERMISSION_PHOTOS is DISABLED"before the macro guard inPhotoPermissionStrategy.m— the build failed, confirming the macro was0.Neither
#filenorFileManager.default.currentDirectoryPathresolves to a path that can walk up to the project root containingpubspec.yaml+ios/Runner/Info.plist. AllPERMISSION_*macros default to"0", every strategy compiles as anUnknownPermissionStrategystub, andPHPhotoLibrary.requestAuthorizationis never called → iOS never registers the permission → no Photos toggle in Settings.Scope
Not just Photos —
PERMISSION_CAMERA,PERMISSION_MICROPHONE, andPERMISSION_BLUETOOTHare all affected (confirmed via#errorin all three strategies).Workaround
Mahfa commentedon Jul 20, 2026
@RockyJT215 had the same issue , @Pachebel answer solved it for me
Pachebel commentedon Aug 11, 2026
Hi everyone!
The flavors part (and a few smaller issues) should be fixed in my latest two PRs: #1553 and #1554.
Please try permission_handler_apple 9.6.0 and let me know if you find any problems.
If everything runs fine, I think this issue can be closed.
deandreamatias commentedon Aug 13, 2026
For me the version 9.6.0 solved the bugs. I sent a version to iOS and I not received the email with ITMS-90683
deandreamatias commentedon Aug 13, 2026
@lahteefmitco please close the issue
narumi147 commentedon Sep 13, 2026
I also have concerns about relying on environment variables (
PERMISSION_HANDLER_INFO_PLIST,PERMISSION_NOTIFICATIONS,PERMISSION_CRITICAL_ALERTS) to configure permissions.Using
launchctl setenvmakes project-specific configuration part of the user's login session. When working on multiple Flutter projects with different permission requirements, developers have to manage these values manually and restart Xcode to pick up changes. An absolute Info.plist path is also machine-specific and cannot be shared reliably through version control.Permission configuration should ideally live in the project, be version-controlled, and work consistently for local development and CI. Environment variables are useful as optional overrides, but they should not be required for a standard build.
Could we have a project-scoped configuration mechanism that works directly from Xcode without requiring session-wide environment variables or manual cache clearing?
jellynoone commentedon Oct 6, 2026
I had a hard time running apps and getting permissions to work.
I run the app via VSCode's quick actions over main. My app is usually located on a deeper level.
Running this the app just failed at runtime.
Clearing
~/Library/Developer/Xcode/DerivedDataand running from the terminal at the root of the project correctly built the app with permissions.It seems to me the current working directory from where the project is build is important to permissions discovery.
Versions: