v5.0.0

[zoontek]

As iOS 18 / Android 15 are around the corner, it's time to publish a new major version, as it will needs the latest Xcode version (v16) to be built. Let's perform some changes to improve this library in the same time.

I'm opening this to discuss about some points. I think it will be for the better, but I would love a community confirmation about them:

• Add limited contacts support (on iOS 18+) ✅
• Drop support for iOS < 13.4 ✅
• Drop support for Android < 6.0 ✅
• Remove the UNAVAILABLE status, return BLOCKED instead (as it cannot be requested). That's one less thing to check, and it allows me to solves this issue. ✅
• Migrate the Android code to Kotlin ✅
• ~Make check and checkMultiple synchronous~
• Make check and checkMultiple return a boolean (granted) (as Android will never return blocked on check, you have to call request to get the info anyway) ✅

And, this is extra, but:

• Add hooks. const [granted, request] = usePermission(…) might be a thing, let's see how we can make it reactive.
• Allow location permission escalation (closes https://github.com/zoontek/react-native-permissions/pull/716)
• Add SCHEDULE_EXACT_ALARM permission (closes https://github.com/zoontek/react-native-permissions/pull/878)

[fobos531]

About hooks and reactivity, especially in context of permissions, this github thread at expo has some interesting insight on the API design: https://github.com/expo/expo/pull/31171#discussion_r1731486654

[guillempuche]

Hooks!

[zoontek]

I published a beta version, try it: yarn add react-native-permission@next / npm i --save react-native-permission@next

Beta changelog

• Drop support for React native < 0.73, iOS < 13.4 and Android < 6
• Add LIMITED contacts permissions support (requires Xcode 16 beta)
• Rewrite android codebase in Kotlin
• Remove the UNAVAILABLE status, BLOCKED is now returned in such cases
• Unify all platforms to a unique permission flow
• check, checkMultiple and checkNotifications now return granted boolean instead of statuses (as it was not truly possible on Android to determine if it was BLOCKED without requesting it)
• requestNotifications now accept a rationale argument

EDIT: Just published a second beta that switch back to async check / checkMultiple, as after some tests it was too slow for some iOS permissions (Face ID…), and was locking the JS thread. Plus, it reduces the amount of breaking changes / add back working windows compat.

[zoontek]

Just published beta 2 to fix an issue with bob + the expo plugin (more infos https://github.com/callstack/react-native-builder-bob/pull/598#issuecomment-2350930474)

[valeeum]

I don't quite understand what the flow would be to check and then request permissions if the check method returns a boolean. what if a user provides limited permissions but I want to force granted permissions. how would i know that permissions are limited and present user to click on a button to be redirected to Linking.openSettings().

Right now, i have this block of code. But if a user is presented this for the first time and they select limited permissions, then once request completes, they will be redirected to settings immediately.

const contactsPermissionResult = await check(PERMISSIONS.IOS.CONTACTS);
if (!contactsPermissionResult) {
  request(PERMISSIONS.IOS.CONTACTS)
    .then(status => {
      if (status === RESULTS.GRANTED) {
        //...dismiss modal
      } else {
        Linking.openSettings();
      }
    })
  }

[zoontek]

@valeeum The flow is aligned with the Android one.

In your example, request resolve with a PermissionStatus, so you can verify if it's GRANTED or LIMITED, and no need to redirect the user to settings in such case.

[zoontek]

Published beta 3 with iOS location permission upgrade support.

[martinpoulsen]

I have verified the iOS location permission upgrade from "when in use" to "always", it works great 👍 Thank you for adding that 🙏

[martinpoulsen]

In my company's use case, we differentiate the UI/UX context for permission requests to a high degree based on both platform and whether it's possible to request a given permission from within the app vs sending the user to settings. With the changed signature for check and checkMultiple, we loose the information we need for this UI/UX customisation.

I understand the problem with the current check signature where the returned PermissionStatus is sometimes misleading e.g. in case of Android (due to the native APIs only reveals whether the permission is granted or not) so I see the motivation for the change. However, we would be very sad to lose this information from the iOS permission checks.

I have a suggestion for a different solution - inspired by the signature of checkNotifications. Could check and checkMultiple have a simlar response structure containing both a granted boolean and an optional status in case the platform APIs support it? I.e.

check: (permission: Permission) => Promise<{granted: boolean; status?: PermissionStatus}>