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 when the app permissions are requested, i.e. upfront during download and install, or during runtime.  iOS requires explicitly requesting permissions at runtime and Android is also progressing in the same direction as of Android 6 (Marshmallow) and working through the install base.  Apps request permissions either during download and 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, 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.  The permissions can be requested during runtime – as and when needed – when a device is running Android 6.0 (Marshmallow) and the app targeting SDK 23 and higher (i.e. targetSdkVersion is at least 23).  There are some important 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, in Settings App on a device running Android 6 (Marshmallow) or higher regardless of what SDK you are targeting.
  • Permissions have to be declared in the manifest regardless of targeted SDK or Android OS version and are displayed to user during download.

Growth considerations related to requesting 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 “Give microphone access to record and morph your recorded voice”.
    Screen Shot 2016-08-29 at 3.51.53 PM
  • 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.  For instance, if you are targeting iOS 8 or higher, you can launch the app’s settings using:
    NSURL* u = [NSURL URLWithString:UIApplicationOpenSettingsURLString];
    [[UIApplication sharedApplication] openURL:u];
  • 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, check it out at: Science and Strategy behind growth hacks

App stores can help improve the overall permissions experience

Similar to how In-app purchases are listed on the iOS app store, and available to users when they are considering 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 provided by app publishers.

GP

The Settings App should list the app publisher provided explanations (e.g. NSContactsUsageDescription in Info.plist) under each privacy and app settings. 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.  Similar, the OS could show the app publisher provided explanations in settings for an app.

Posted by Dickey Singh

Dickey Singh is the CEO and co-founder at Pyze and has over two decades of experience in mobile, Big Data and SaaS. He started Pyze to help app publishers engage, retain and grow their mobile users using automation. https://twitter.com/DickeySingh Get Pyze: https://pyze.com