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 Handle upgrading from location when in use to location always on iOS #716)
• Add SCHEDULE_EXACT_ALARM permission (closes feat(android): add schedule exact alarm permission #878)

[fobos531]

About hooks and reactivity, especially in context of permissions, this github thread at expo has some interesting insight on the API design: expo/expo#31171 (comment)

[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]

Juste published beta 2 to fix an issue with bob + the expo plugin (more infos callstack/react-native-builder-bob#598 (comment))

[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();
      }
    })
  }