Accessing User Data
User privacy is paramount. To help people trust your app, it’s crucial to be transparent about the privacy-related data and resources you require and how you use them. For example, you must request permission to access:
- Personal data, including location, health, financial, contact, and other personally identifying information
- User-generated content like emails, messages, calendar data, contacts, gameplay information, Apple Music activity, HomeKit data, and audio, video, and photo content
- Protected resources like Bluetooth peripherals, home automation features, Wi-Fi connections, and local networks
- Device capabilities like camera and microphone
IMPORTANT Beginning in iOS 14.5 and iPadOS 14.5, you must use the AppTrackingTransparency framework to request the user’s permission if you want to track them or access their device’s advertising identifier. To learn more, see User Privacy and Data Use.
When you submit a new or updated app, you must provide details about your privacy practices and the privacy-relevant data you collect so the App Store can display the information on your product page. (You can manage this information at any time in App Store Connect.) People use the privacy details on your product page to make an informed decision before they download your app. To learn more, see App privacy details on the App Store.
Requesting Permission to Access User Data and Resources
The system provides a standard alert that lets people view your request to access their private information or protected resources. They can also view your request and update their choice in Privacy settings. You supply a description of why your app needs the items and determine when to show the alert; the system handles all other parts of the alert experience. Here are several examples:
Write copy that clearly describes how your app uses the data you’re requesting. The standard alert displays your copy (called a purpose string or usage description string) after your app name and before the buttons people use to grant or deny their permission. Aim for a brief, complete sentence that’s straightforward, specific, and easy to understand. Use sentence case, avoid passive voice, and include a period at the end. For developer guidance, see Requesting Access to Protected Resources and App Tracking Transparency.
|Example purpose string||Notes|
|The app records during the night to detect snoring sounds.||An active sentence that clearly describes how and why the app collects the data.|
|Microphone access is needed for a better experience.||A passive sentence that provides a vague, undefined justification.|
|Turn on microphone access.||An imperative sentence that doesn’t provide any justification.|
Request permission only when your app clearly needs access to the data. It’s natural for people to be suspicious of a request for personal information, especially if there’s no obvious need for it. Request permission only when people actually use features that need their data. For example, you might request access to the device location only when a user wants to know how to get to your store.
TIP Check the system to see whether Location Services is enabled before you try to access location information. Using this information, you may be able to avoid presenting the alert until it’s necessary. For developer guidance, see Requesting Authorization for Location Services.
Request permission at launch only when the data is necessary for your app to function. People are less likely to be bothered by a request when it’s obvious why your app needs the information. If you want to perform app tracking as soon as people launch your app, you must display the system-provided alert before you collect any tracking data.
Displaying Custom Messaging Before the Alert
Ideally, people already know why you’re requesting their permission based on context, but if it’s essential to provide additional details, you can display a custom message before the alert appears.
Make it clear that opening the system alert is the only action people can take in your custom-messaging screen. People can interpret a pre-alert message as a delaying tactic, so it’s critical to let them quickly dismiss the message and view the system alert. If you display a custom screen that precedes a privacy-related permission request, it must offer only one action, which must display the system alert. Use a word like "Continue" to title the action; don’t use "Allow" or other terms that might make people think they’re granting their permission or performing other actions within your custom screen.
Clarifying Tracking Requests
App tracking is a sensitive issue. In some cases, it might make sense to display custom messaging that clearly describes the benefits of tracking.
Never precede the system-provided alert with custom messaging that could confuse or mislead people. People sometimes tap quickly to dismiss alerts without reading them. A custom messaging screen that takes advantage of such behaviors to influence choices will lead to rejection by App Store Review.
There are several prohibited custom-messaging designs that will cause rejection. Some examples are offering incentives, displaying a screen that looks like a request, displaying an image of the alert, and annotating the screen behind the alert (shown below). For guidance, see App Store Review Guidelines: 5.1.1 (iv).