Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Requesting Personal User Data in Apps

DZone's Guide to

Requesting Personal User Data in Apps

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.

· Mobile Zone
Free Resource

Download this comprehensive Mobile Testing Reference Guide to help prioritize which mobile devices and OSs to test against, brought to you in partnership with Sauce Labs.

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:

Image title

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

Image title


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.Screen Shot 2016-08-29 at 10.40.53 AM
  • 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.

Analysts agree that a mix of emulators/simulators and real devices are necessary to optimize your mobile app testing - learn more in this white paper, brought to you in partnership with Sauce Labs.

Topics:
mobile ,user data ,personal data ,private data ,ios ,android ,pyze

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}