Feature Request: iOS Provisional Notification Permissions

[azack]

🚀 Feature Requests

• Add support for distinguishing the iOS provisional notification permission for checking current permission level & requesting full permission

Contextualize the feature

In iOS 12, UNAuthorizationStatusProvisional was added as a case to UNAuthorizationStatus. This allows a developer to request notification permissions in a way that are initially approved without the user being prompted on a trial basis, but with the restriction that users are not actively interrupted when a notification is received. It is up to the user to check Notification Center themselves and decide if they want to keep the notifications. Much more background in Apple's article Asking permission to use notifications.

Currently, if an application has already been granted provisional notification permissions, retrieving the permission via permission_handler's NotificationPermissionStrategy permissionStatus method will return PermissionStatusGranted. This does not reflect the actual permission, which would cause client code to think permission is fully granted. If client code wanted to "upgrade" a user's permission to fully authorized by prompting them to enable this permission, we can't, because requestPermission: checks the permission status first and thinks it is already granted, showing no prompt. By adding support for provisional access, client code could correctly trigger the OS permission dialog when explicit authorized access is desired.

If there is a downside to adding this, it's that changing the permission_handler_platform_interface may be unavoidable to support this additional permission type. It is unclear to me if this could be done straightforwardly without a breaking change / a major version update; adding to the enum would mean that consumers of the api handling PermissionStatus in a switch statement could potentially require upgrading.

For additional context, There does seem to be precedence for adding a more niche permission as a status to the overall interface, as the limited status was added for that unique case (although was not versioned as a breaking change).

Describe the feature

A possible implementation

• [ ] Add provisional (PermissionStatusProvisional) as a possible PermissionStatus. This status would apply to Apple platforms only ("iOS").
• [ ] Add provisional handling to the touch points in permission_handler_platform_interface: PermissionStatus, PermissionStatusValue, statusByValue
• [ ] Add isProvisional to PermissionStatusGettersand FuturePermissionStatusGetters in permission_status.dart
• [ ] Assign a permissionStatus = PermissionStatusProvisional in NotificationPermissionStrategy when settings.authorizationStatus == UNAuthorizationStatusProvisional with platform availability checked (iOS 12+)
• [ ] Check for PermissionStatusProvisional in requestPermission: with platform availability (i.e. iOS 12 is @available()) and only call the completionHandler early if the status is both not denied and not provisional.
• [ ] Add a isProvisional helper method in permission_handler.dart

A nice to have

A further enhancement would be a way to request notification permissions provisionally as well. I think looking at the current API and again using the photo permission feature PR as an example (specifically how it added PermissionGroupPhotosAddOnly), it might make sense to add a new provisionalNotification as a Permission type so that it could be requested explicitly, but maybe there's a better way to do that. In this scenario, NotificationPermissionStrategy.m would also support the provisional attribute of UNAuthorizationOptions that are passed to UNUserNotificationCenter requestAuthorizationWithOptions

Scope Limit

This feature request does not extend to another new notification permission type, ephemeral, which was added in iOS 14 for App Clips. Just mentioning here in case anyone is searching for that in the future. For now, app clips in Flutter are an experimental preview.

Platforms affected (mark all that apply)

• [x] :iphone: iOS
• [ ] :robot: Android

[tp]

adding to the enum would mean that consumers of the api handling PermissionStatus in a switch statement could potentially require upgrading.

Exactly this happened to us, so I would've considered this a breaking change requiring a major release version.

This was especially surprising, as the code in questions only handles calendar permissions, and now it fails due to a new case added for notifications.

I think a similar "gap" already exists with the limited case which seems only applicable to photos (and only on iOS).

Personally I would think this would warrant creating individual permission enums for each use case, closer mapping the possible underlying platform cases.

[mvanbeusekom]

Personally I would think this would warrant creating individual permission enums for each use case, closer mapping the possible underlying platform cases.

We are planning a refactor of the plugin with the intention to expose the native APIs through Dart and have an additional abstraction on top of that exposing a cross-platform interface.

This should allow developers to decide if the cross-platform interface is sufficient or if they'd have platform specific needs to access the platform native interface (all through Dart of course). This is however a large refactor which will take a few months to complete, just know that we are working on it.

[derekpitts28]

Any updates on this?