Accessing User Data
Location Services allows apps to determine people’s approximate location geographically, the direction they’re pointing their device, and the direction in which they’re moving. In iOS 6.0 and later, other system services—such as Contacts, Calendar, Reminders, and Photo Library—also allow apps to access the data people store in them.
Although people appreciate the convenience of using an app that already knows a lot about them, they also expect to have the option of keeping their data private. For example, people like being able to automatically tag content with their physical location or find friends that are currently nearby, but they also want to be able to disable such features when they don’t choose to share their location with others. (To learn more about how to make your app location-aware, see Location and Maps Programming Guide.)
The following guidelines can help you ask for user data in ways that help people feel comfortable.
Make sure users understand why they’re being asked to share their personal data. It’s natural for people to be suspicious of a request for their personal information if they don’t see an obvious need for it. To avoid making users uncomfortable, make sure the alert appears only when they attempt to use a feature that clearly needs to know their information. For example, people can use Maps when Location Services is off, but they see an alert when they access the feature that finds and tracks their current location.
Describe why your app needs the information, if it’s not obvious. You can provide text that appears in the alert, below a system-provided title such as ““App Name” Would Like to Access Your Contacts”. You want this text to be specific and polite so that people understand why you’re asking for access to their information and don’t feel pressured. Your reason text should:
Not include your app name. The system-provided alert title already includes your app name.
Clearly describe why your app needs the data. If appropriate, you might also explain ways in which your app will not use the data.
Use user-centric terminology and be localizable.
Be as short as possible, while still being easy to understand. As much as possible, avoid supplying more than one sentence.
Use sentence-style capitalization. (Sentence-style capitalization means that the first word is capitalized, and the rest of the words are lowercase unless they are proper nouns or proper adjectives.)
Ask permission at app startup only if your app can’t perform its primary function without the user’s data. People will not be bothered by this if it’s obvious that the main function of your app depends on knowing their personal information.
Avoid making programmatic calls that trigger the alert before the user actually selects the feature that needs the data. This way, you avoid causing people to wonder why your app wants their personal information when they’re doing something that doesn’t appear to need it. (Note that getting the user’s Location Services preference does not trigger the alert.)
For location data, check the Location Services preference to avoid triggering the alert unnecessarily. You can use Core Location programming interfaces to get this setting (to learn how to do this, see Core Location Framework Reference). With this knowledge, you can trigger the alert as closely as possible to the feature that requires location information, or perhaps avoid an alert altogether.