Users have to explicitly grant permissions to iOS and Android apps so the apps can have access to a user’s personal and private data.  The two mobile operating systems have in the past differed regarding when the app permissions are requested, i.e. upfront during download and install or during runtime.  However, Android is also progressing in the direction of explicitly requesting permissions when needed at runtime, similar to the permissions request model of iOS.

Apps request permissions either during install (Android only), upon first app start or at runtime as and when each specific permission is needed.

Permissions can be reviewed and changed in the Settings app in iOS (under Privacy). iOS 10 screenshots shown:

Permissions can be reviewed and changed in the Settings app (under Privacy and Safety on Android M onwards).  Android 7 / Nougat screenshot shown.

What Constitutes Private and Personal Data?

A users location, contacts, calendars, health etcetera is private information and apps must explicitly request them.  Apps generally request the following major permissions.

• Location Services access when app is in foreground, or foreground and background (iOS)
• Approximate or Precise Geo Location (Android)
• Contacts or Address book (iOS and Android),
• Calendars  (iOS and Android),
• Reminders  (iOS),
• Photos (iOS),
• Bluetooth sharing (iOS),
• Microphone (iOS and Android),
• Speech Recognition (iOS)
• Camera  (iOS and Android),
• Health (iOS),
• HomeKit (iOS)
• Media library (iOS),
• Motion and Fitness (iOS) or body sensors (Android)
• SMS and MMS messaging (Android),
• External storage (Android)
• Device and app history: logs, dumps, running app list, web bookmarks & history (Android)
• WiFi Connection information (Android)

Requesting Permissions at Runtime

iOS

On iOS permissions should be requested at runtime as and when needed. However, for some apps it makes sense to ask the permissions upfront.  For example, a simple contact de-duper utility app needs access to contacts before it can look for duplicate contacts.  It could show a screen explaining the apps’ function and request the permission interactively on first launch.

Android

On Android, historically permissions are embedded in a manifest file and displayed to a user when the user is downloading the app from the Google Play app store.  However, permissions can be requested during runtime as and when needed, when a device is running Android 6.0 (Marshmallow), and for apps targeting SDK 23 and higher (i.e. targetSdkVersion is at least 23).  There are some considerations however:

• If the user’s device is running a Android version lower than Android 6.0 (i.e. lower than Marshmallow), users have to grant the permission during download to continue installing.
• If your app is targeting SDK 22 or lower, users have to grant the permission during download to continue installing.
• If the user’s device is running Android 6.0 or higher (i.e. Marshmallow, Nougat or higher), AND your app’s target SDK is 23 or higher, the app must request app permissions during runtime.
• Regardless of the targeted SDK, users running Android 6.0 (Marshmallow) or higher can grant and deny permissions in the Settings App (under Privacy and Safety)
• App publishers must account for cases when the user denies a permission, either in Settings App on a device running Android 6 (Marshmallow) or higher, or when asked during runtime for apps targeting SDK 23 or higher.
• Permissions have to be declared in the manifest regardless of targeted SDK or Android OS version and are displayed to user during download.

Considerations When Asking for Permissions

There are a quite a few considerations when asking for permissions that we are listing here for app publishers.

• Access to personal data should only be requested via app permission requests when the app clearly and absolutely needs it.
• It is always a good idea to provide a convincing reason why the app needs the permission, even if it is obvious.  Clearly communicate to users what to expect when asking for an app permission. On iOS, you can customize the subtitle to include text explaining what text to use. For example, to customize the text for accessing contacts specify a string for key NSContactsUsageDescription in Info.plist.
• Avoid asking for permissions at launch, unless your app cannot continue without a specific permission.
• Avoid bombarding the user with a flood of different permission requests, one after another.
• If you can delay asking for permissions, ask for permissions when the user is engaged, activated or when it makes the most sense. For example, delay asking for permissions until the user has used the app for at least 7 times and / or created some content.
• Let users interactively and explicitly request permissions.  For instance, users will be more likely to grant permission when they see a button “Let CoolApp access Microphone” along with an explanation “By giving microphone access to CoolApp you can record your voice and access the voice morphing features”.Here is another example of Periscope App, letting users click on a button explicitly before invoking iOS api that triggers asking for permissions.
• Not having the right permissions changes the usability and experience of your app.  Design experiences for scenarios when a permission is granted, denied, initially denied and later granted, initially granted and later denied from the Settings app.
• Try to get the permission the first time.   For users who have explicitly declined to give a permission, have a fallback where you redirect to the settings app so users may reenable the app permissions.
• Detect whether asking for a permission makes sense.  For example, check to see if Location Services is enabled and delay the alert to a more appropriate time and provide an explanation why location services must be turned on.
• We wrote about permissions earlier.  See Science and Strategy behind growth hacks

Improving the App Permissions Model

Similar to how In-app purchase are listed on the iOS app store, and available to users before downloading an app, app stores should list the permissions required by apps in an end-user consumable way.  Google Play does list permissions an app requires but does not list the explanations from app publishers.

App publishers should clearly explain what value the user gets by providing personal information to your app.

The Settings App should list the app publisher provided explanations under privacy section. For instance, it may be clear to a user why Health app needs motion and fitness personal data, but is not clear to a user why Waze and Nexar need them.