Mastering Permissions in React Native with react-native-permissions

Why Use react-native-permissions?

Mobile apps rarely stay inside pure UI. They need camera, photos, location, microphone, notifications, Bluetooth, motion, contacts, or biometrics. Each of those features crosses a trust boundary, so iOS and Android force the app to ask clearly and handle the user's answer correctly.

`react-native-permissions` gives React Native teams a shared vocabulary for that flow: `check`, `request`, `RESULTS`, `PERMISSIONS`, notification helpers, and settings links. It does not remove platform rules, but it makes them easier to centralize.

Installation and Platform Setup

The package supports current React Native releases and provides platform-specific setup for iOS, Android, Expo, and Windows. Keep the configuration narrow: only add permissions the product actually uses.

npm install react-native-permissions
# or
yarn add react-native-permissions

setup_permissions([
  'Camera',
  'LocationWhenInUse',
  'Microphone',
]);

<uses-permission android:name="android.permission.CAMERA" />
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />

plugins: [
  ['react-native-permissions', { iosPermissions: ['Camera'] }],
],
android: {
  permissions: ['android.permission.CAMERA'],
}

Understanding Permission Statuses

The most important part is not the permission constant; it is the state machine. Good permission handling reacts differently to unavailable, denied, blocked, granted, and limited states.

A Practical Permission Flow

In production, avoid asking again and again. Check first. If it is granted, continue. If it is denied, ask at the right moment. If it is blocked, explain the issue and open app settings.

import {check, openSettings, request, RESULTS} from 'react-native-permissions';

async function ensurePermission(permission) {
  const status = await check(permission);

  if (status === RESULTS.GRANTED || status === RESULTS.LIMITED) {
    return status;
  }

  if (status === RESULTS.BLOCKED) {
    await openSettings('application');
    return status;
  }

  if (status === RESULTS.DENIED) {
    return request(permission);
  }

  return status;
}

Camera Permission Example

Camera access is a good first abstraction because it exists on both platforms and commonly appears in profiles, KYC, delivery, social, healthcare, and ecommerce apps.

import {Platform} from 'react-native';
import {PERMISSIONS, RESULTS, check, openSettings, request} from 'react-native-permissions';

const cameraPermission = Platform.select({
  ios: PERMISSIONS.IOS.CAMERA,
  android: PERMISSIONS.ANDROID.CAMERA,
});

export async function requestCameraPermission() {
  if (!cameraPermission) return RESULTS.UNAVAILABLE;

  const current = await check(cameraPermission);

  if (current === RESULTS.GRANTED) return current;
  if (current === RESULTS.BLOCKED) {
    await openSettings('application');
    return current;
  }

  return request(cameraPermission);
}

Location Permission Example

Location needs extra care. On iOS, decide whether `LOCATION_WHEN_IN_USE` is enough before considering background location. On Android 11+, one-time permissions can be revoked after the app is backgrounded or closed.

import {Platform} from 'react-native';
import {PERMISSIONS, check, request} from 'react-native-permissions';

const locationPermission = Platform.select({
  ios: PERMISSIONS.IOS.LOCATION_WHEN_IN_USE,
  android: PERMISSIONS.ANDROID.ACCESS_FINE_LOCATION,
});

export async function ensureLocationPermission() {
  if (!locationPermission) return 'unavailable';

  const status = await check(locationPermission);
  return status === 'denied' ? request(locationPermission) : status;
}

Using the Permission Service in a Component

Keep UI components focused on user actions. The component should not know every platform detail; it should call a small service and react to the final status.

function ExampleScreen() {
  const handleCamera = React.useCallback(async () => {
    const status = await requestCameraPermission();

    if (status === 'granted') {
      // Open camera flow here
    }
  }, []);

  return <Button title="Use camera" onPress={handleCamera} />;
}

Notifications, Settings, and Multiple Permissions

Notifications deserve a separate flow because platform rules keep changing. On Android 13+, runtime notification permission applies when targeting SDK 33 or later. On iOS, you can request options such as alert and sound. For blocked or disabled settings, use `openSettings` and guide the user instead of trapping them in a dead end.

For screens that need more than one permission, use `checkMultiple` for visibility and `requestMultiple` when the user chooses to continue. Do not request a bundle of unrelated permissions at app launch.

Best Practices for Production Apps

Testing Permissions with Jest

Native modules are not available in normal Jest runs. The package provides a mock entry, so add it to your Jest setup file and test your permission branches without relying on a device prompt.

jest.mock('react-native-permissions', () => require('react-native-permissions/mock'));

Common Mistakes to Avoid

• Requesting every permission during onboarding.
• Adding vague iOS usage descriptions such as “needed”.
• Forgetting to rerun `pod install` after iOS setup changes.
• Expecting Android `check` to behave exactly like iOS.
• Ignoring limited photo access and blocked settings states.
• Testing only on simulators and missing real-device behavior.

Frequently Asked Questions

Conclusion

Mastering permissions in React Native is less about memorizing constants and more about designing a respectful flow. Ask only when the feature needs it, explain the value clearly, handle blocked and limited states, and centralize the logic so the rest of the app stays clean.

Technical references used: official react-native-permissions package documentation and React Native PermissionsAndroid documentation.