How do permissions work on iOS and Android? What is the difference between install-time and runtime permissions?

Question

Accepted Answer

Permissions are a critical part of mobile development because they control your app's access to sensitive device features and user data. Both iOS and Android implement permission systems, but they work differently in important ways.

On Android, permissions are divided into two categories: normal permissions and dangerous permissions. Normal permissions, like accessing the internet or setting an alarm, are granted automatically at install time because they pose minimal risk to user privacy. These are declared in AndroidManifest.xml and require no user interaction. Dangerous permissions, like accessing the camera, microphone, location, contacts, or storage, must be requested at runtime. Starting with Android 6.0 (API level 23), apps must explicitly ask the user for dangerous permissions when the feature is needed, not at install time.

The Android runtime permission flow works like this. First, check if the permission is already granted using ContextCompat.checkSelfPermission. If not granted, you can optionally check shouldShowRequestPermissionRationale to determine if you should explain why the permission is needed. Then request the permission using the ActivityResultContracts.RequestPermission API. The system shows a dialog, and the user can grant or deny. If the user denies twice, Android stops showing the dialog and the user must manually enable the permission in the app's settings.

On iOS, all sensitive permissions require runtime authorization. There is no concept of install-time permission grants. iOS uses a simpler but stricter model. Each permission type requires a usage description string in Info.plist that explains why your app needs the access. This string is displayed to the user in the permission dialog. If you forget to include the usage description, your app will crash when requesting the permission in development and will be rejected during App Store review.

iOS permission states include not determined (user has not been asked yet), authorized, denied, and restricted (parental controls or device management prevent access). Once a user denies a permission on iOS, your app cannot show the permission dialog again. You must direct the user to the Settings app to change the permission manually.

Both platforms support location permissions with granular options. Android offers fine location (GPS) and coarse location (network-based) as separate permissions. iOS offers "While Using the App" and "Always" location access, with "While Using" being the default option presented first. Both platforms have added "approximate location" options in recent versions to give users more privacy control.

For cross-platform frameworks, libraries like react-native-permissions for React Native and the permission_handler package for Flutter provide unified APIs that abstract platform differences while still requiring you to configure the platform-specific manifest entries and usage descriptions.