… options expo#20072

On iOS, the permissions for Notification can be requested with a set of [options](https://developer.apple.com/documentation/usernotifications/unauthorizationoptions). The most common ones are to display alerts or play sounds, but they can also enable notifications on CarPlay displays, or enable critical alerts. Over the course of its lifetime, an app may introduce aditional capabilities, such as critical alerts or other, newly introduced iOS features and thus, must call `requestAuthorization(options:completionHandler:)` again with a new set of options. Expo Notifications supports all these [options](https://docs.expo.dev/versions/latest/sdk/notifications/#requestpermissionsasyncrequest-notificationpermissionsrequest-promisenotificationpermissionsstatus) for  `requestPermissionsAsync`.

The issue is, that after an app is newly installed on a device, the first call to `Notification.requestPermissionsAsync` will prompt the user, and set the given options. **However, subsequent calls will have no effect.**
This means, for the user to take advantage of new features, they will have to de-install and re-install the app, which is completely unacceptable.

The root of the problem can be found in [EXPermissionsService.m:111](https://github.com/expo/expo/blob/168ee43f71f005baa11edf98e518593443e1807a/packages/expo-modules-core/ios/Services/Permissions/EXPermissionsService.m#L111):

```objc
  BOOL isGranted = [EXPermissionsService statusForPermission:permission] == EXPermissionStatusGranted;
  permission[@"granted"] = @(isGranted);

  if (isGranted) {
    return onResult(permission);
  }

  [self askForGlobalPermissionUsingRequesterClass:requesterClass
                                     withResolver:onResult
                                     withRejecter:reject];
```

This means that permissions are only ever requested again, if permission has not previously been granted. This however **does not consider different options**, but only if any sort of notification permissions have been granted. This means that if previously only Alerts have been requested, a new request for Alerts and Sounds will be ignored.

On iOS, it is perfectly acceptable to call `requestAuthorization(options:completionHandler:)` repeatedly:
> subsequent calls to this method (even with different options do not prompt the user again. It is best practice on iOS to call this method liberally (e.g. at every startup), and the performance hit should not be different from getting the permission status.

Also not that several tutorials suggest to check the permission status first, and then requesting it. This is — at least for iOS — not advisable.

Therefore the method `askForPermissionUsingRequesterClass` was removed entirely, and instead the method `askForGlobalPermissionUsingRequesterClass` was renamed appropriately.

… options expo#20072

On iOS, the permissions for Notification can be requested with a set of [options](https://developer.apple.com/documentation/usernotifications/unauthorizationoptions). The most common ones are to display alerts or play sounds, but they can also enable notifications on CarPlay displays, or enable critical alerts. Over the course of its lifetime, an app may introduce aditional capabilities, such as critical alerts or other, newly introduced iOS features and thus, must call `requestAuthorization(options:completionHandler:)` again with a new set of options. Expo Notifications supports all these [options](https://docs.expo.dev/versions/latest/sdk/notifications/#requestpermissionsasyncrequest-notificationpermissionsrequest-promisenotificationpermissionsstatus) for  `requestPermissionsAsync`.

The issue is, that after an app is newly installed on a device, the first call to `Notification.requestPermissionsAsync` will prompt the user, and set the given options. **However, subsequent calls will have no effect.**
This means, for the user to take advantage of new features, they will have to de-install and re-install the app, which is completely unacceptable.

The root of the problem can be found in [EXPermissionsService.m:111](https://github.com/expo/expo/blob/168ee43f71f005baa11edf98e518593443e1807a/packages/expo-modules-core/ios/Services/Permissions/EXPermissionsService.m#L111):

```objc
  BOOL isGranted = [EXPermissionsService statusForPermission:permission] == EXPermissionStatusGranted;
  permission[@"granted"] = @(isGranted);

  if (isGranted) {
    return onResult(permission);
  }

  [self askForGlobalPermissionUsingRequesterClass:requesterClass
                                     withResolver:onResult
                                     withRejecter:reject];
```

This means that permissions are only ever requested again, if permission has not previously been granted. This however **does not consider different options**, but only if any sort of notification permissions have been granted. This means that if previously only Alerts have been requested, a new request for Alerts and Sounds will be ignored.

On iOS, it is perfectly acceptable to call `requestAuthorization(options:completionHandler:)` repeatedly:
> subsequent calls to this method (even with different options do not prompt the user again. It is best practice on iOS to call this method liberally (e.g. at every startup), and the performance hit should not be different from getting the permission status.

Also not that several tutorials suggest to check the permission status first, and then requesting it. This is — at least for iOS — not advisable.

Therefore the method `askForPermissionUsingRequesterClass` was removed entirely, and instead the method `askForGlobalPermissionUsingRequesterClass` was renamed appropriately.

This was tested with my [test
app](https://github.com/below/ExpoNotificationIssue).

… options expo#20072

On iOS, the permissions for Notification can be requested with a set of [options](https://developer.apple.com/documentation/usernotifications/unauthorizationoptions). The most common ones are to display alerts or play sounds, but they can also enable notifications on CarPlay displays, or enable critical alerts. Over the course of its lifetime, an app may introduce aditional capabilities, such as critical alerts or other, newly introduced iOS features and thus, must call `requestAuthorization(options:completionHandler:)` again with a new set of options. Expo Notifications supports all these [options](https://docs.expo.dev/versions/latest/sdk/notifications/#requestpermissionsasyncrequest-notificationpermissionsrequest-promisenotificationpermissionsstatus) for  `requestPermissionsAsync`.

The issue is, that after an app is newly installed on a device, the first call to `Notification.requestPermissionsAsync` will prompt the user, and set the given options. **However, subsequent calls will have no effect.**
This means, for the user to take advantage of new features, they will have to de-install and re-install the app, which is completely unacceptable.

The root of the problem can be found in [EXPermissionsService.m:111](https://github.com/expo/expo/blob/168ee43f71f005baa11edf98e518593443e1807a/packages/expo-modules-core/ios/Services/Permissions/EXPermissionsService.m#L111):

```objc
  BOOL isGranted = [EXPermissionsService statusForPermission:permission] == EXPermissionStatusGranted;
  permission[@"granted"] = @(isGranted);

  if (isGranted) {
    return onResult(permission);
  }

  [self askForGlobalPermissionUsingRequesterClass:requesterClass
                                     withResolver:onResult
                                     withRejecter:reject];
```

This means that permissions are only ever requested again, if permission has not previously been granted. This however **does not consider different options**, but only if any sort of notification permissions have been granted. This means that if previously only Alerts have been requested, a new request for Alerts and Sounds will be ignored.

On iOS, it is perfectly acceptable to call `requestAuthorization(options:completionHandler:)` repeatedly:
> subsequent calls to this method (even with different options do not prompt the user again. It is best practice on iOS to call this method liberally (e.g. at every startup), and the performance hit should not be different from getting the permission status.

Also not that several tutorials suggest to check the permission status first, and then requesting it. This is — at least for iOS — not advisable.

Therefore the method `askForPermissionUsingRequesterClass` was removed entirely, and instead the method `askForGlobalPermissionUsingRequesterClass` was renamed appropriately.

This was tested with my [test
app](https://github.com/below/ExpoNotificationIssue).

… options expo#20072

On iOS, the permissions for Notification can be requested with a set of [options](https://developer.apple.com/documentation/usernotifications/unauthorizationoptions). The most common ones are to display alerts or play sounds, but they can also enable notifications on CarPlay displays, or enable critical alerts. Over the course of its lifetime, an app may introduce aditional capabilities, such as critical alerts or other, newly introduced iOS features and thus, must call `requestAuthorization(options:completionHandler:)` again with a new set of options. Expo Notifications supports all these [options](https://docs.expo.dev/versions/latest/sdk/notifications/#requestpermissionsasyncrequest-notificationpermissionsrequest-promisenotificationpermissionsstatus) for  `requestPermissionsAsync`.

The issue is, that after an app is newly installed on a device, the first call to `Notification.requestPermissionsAsync` will prompt the user, and set the given options. **However, subsequent calls will have no effect.**
This means, for the user to take advantage of new features, they will have to de-install and re-install the app, which is completely unacceptable.

The root of the problem can be found in [EXPermissionsService.m:111](https://github.com/expo/expo/blob/168ee43f71f005baa11edf98e518593443e1807a/packages/expo-modules-core/ios/Services/Permissions/EXPermissionsService.m#L111):

```objc
  BOOL isGranted = [EXPermissionsService statusForPermission:permission] == EXPermissionStatusGranted;
  permission[@"granted"] = @(isGranted);

  if (isGranted) {
    return onResult(permission);
  }

  [self askForGlobalPermissionUsingRequesterClass:requesterClass
                                     withResolver:onResult
                                     withRejecter:reject];
```

This means that permissions are only ever requested again, if permission has not previously been granted. This however **does not consider different options**, but only if any sort of notification permissions have been granted. This means that if previously only Alerts have been requested, a new request for Alerts and Sounds will be ignored.

On iOS, it is perfectly acceptable to call `requestAuthorization(options:completionHandler:)` repeatedly:
> subsequent calls to this method (even with different options do not prompt the user again. It is best practice on iOS to call this method liberally (e.g. at every startup), and the performance hit should not be different from getting the permission status.

Also not that several tutorials suggest to check the permission status first, and then requesting it. This is — at least for iOS — not advisable.

Therefore the method `askForPermissionUsingRequesterClass` was removed entirely, and instead the method `askForGlobalPermissionUsingRequesterClass` was renamed appropriately.

This was tested with my [test
app](https://github.com/below/ExpoNotificationIssue).