Expo SDK 40 seems to have caused a behavior change in Notifications.requestPermissionsAsync()
which breaks the ability of an iOS app to get provisional notification permission without showing a UI prompt.
With expo-notifications
0.8.2, I seem no longer able to control the parameters sent to the underlying iOS API, requestAuthorizationWithOptions
. It always uses a default set of iOS permissions: {"allowAlert": true, "allowBadge": true, "allowSound": true}
instead of the parameter I pass to the JavaScript method requestPermissionsAsync()
, namely {"ios": {"allowProvisional": true}}
. This is a problem because it causes a user-visible prompt, when instead it should silently acquire the provisional notification permission.
I noticed this commit: 4500a75#diff-c6765520a645c75d39acbb68f4345f534d8124ac3b80b7ba262b4abeed3a4431 by @cHaLkdusT which changed the iOS implementation of requestPermissionsAsync()
. Correct me if I’m wrong, but it looks like the requestedPermissions
parameter, passed in from JavaScript, is now being ignored? The new code involves instantiating a EXUserFacingNotificationsPermissionsRequester
but this object has no knowledge of the parameters I passed to requestPermissionsAsync()
.
Steps to Reproduce
import * as Notifications from 'expo-notifications';
ExpoNotifications.requestPermissionsAsync({
ios: {
allowProvisional: true,
},
});
Expected Behavior vs Actual Behavior (when running on a real iOS device)
- Expected behavior: requestPermissionsAsync() resolves without any UI prompt
- Actual behavior: the phone shows the standard “Allow this app to send you push notifications?” prompt, as if I had not set the “allowProvisional: true” flag.
Thanks for reporting this! Opened a PR to fix this, and we can probably include it in an upcoming patch release for SDK 40😄