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.

Screenshot of the App Privacy screen in an app's App Store product page. The top card in the screen is titled 'Data Used to Track You' and lists contact info, location, and identifiers. The bottom card is titled 'Data Linked to You' and lists financial and contact info, location, purchases, identifiers, and browsing history.

An app’s App Store product page helps people understand the app’s privacy practices before they download it.

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:

  • Screenshot of a permission alert for the Pal About app displaying a purpose string that reads 'Allow Pal About to access your location? Turning on location services allows us to show you when pals are nearby.' Below the string is a small map image containing the Precise On notice and below the map are three buttons in a stack. From the top, the buttons are titled Allow Once, Allow While Using App, and Don't Allow.
  • Screenshot of a permission alert for the Pal About app displaying a purpose string that reads 'Pal About would like to access your photos. Allow access to photos to upload photos from your library.' The string is followed by three buttons in a stack. From the top, the buttons are titled Select Photos, Allow Access to All Photos, and Don't Allow.
  • Screenshot of a permission alert for the Pal About app displaying a purpose string that reads 'Allow Pal About to access your contacts? Find friends using Pal About and add them to your pal network.' The string is followed by three buttons: From the top, the buttons are titled Only While Using the App, Always Allow, and Don't Allow.

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
White check in a green circle to indicate a correct example. The app records during the night to detect snoring sounds. An active sentence that clearly describes how and why the app collects the data.
White X in a gray circle to indicate an incorrect example. Microphone access is needed for a better experience. A passive sentence that provides a vague, undefined justification.
White X in a gray circle to indicate an incorrect example. 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.

Screenshot of an app's pre-alert screen that reads 'Allow tracking on the next screen for special offers and promotions just for you, advertisements that match your interests, an improved personalized experience over time. You can change this option later in the Settings app.' Below the text is a button titled Continue.

White check in a green circle to indicate a correct example.

Screenshot of the Pal About app's pre-alert screen that reads 'Turning on location services allows us to provide features like: Alerts when your pals are nearby, news of events happening near you, tagging and sharing your location.' Below the text is a button titled Continue and below the button is the text 'You can change this later in the Settings app.

White check in a green circle to indicate a correct example.

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).

  • Screenshot of an app's pre-tracking message that reads 'Allow tracking and get a $100 credit toward you next purchase.' Below the text is an image of a dollar sign inside a circle. Below the image is a button titled Get $100 credit, followed on the line below by the word Cancel.

    White X in a gray circle to indicate an incorrect example.

    Don’t offer incentives for granting the request. You can’t offer people compensation for granting their permission, and you can’t withhold functionality or content or make your app unusable until people allow you to track them.

  • Screenshot of an app's pre-tracking message that reads 'Allow tracking for a better experience.' Below the text is a bar graph image that shows four bars increasing in height from left to right. Below the graph is a button titled Allow Tracking, followed on the line below by the words Don't Allow.

    White X in a gray circle to indicate an incorrect example.

    Don’t display a custom message that mirrors the functionality of the system alert. In particular, don’t create a button title that uses "Allow" or similar terms, because people don’t allow anything in a pre-alert screen.

  • Screenshot of an app's pre-tracking message that reads 'Choose Allow when prompted.' Below the text is an image of the system-provided alert with the Allow option circled. Below the image is a button titled Continue.

    White X in a gray circle to indicate an incorrect example.

    Don’t show an image of the standard alert and modify it in any way.

  • Screenshot of an app's pre-tracking message that reads 'Allow tracking for a better experience.' The app's custom message also includes an upward-pointing arrow and the words Choose Allow in the lower third of the screen. Because the system-provided alert displays on top of the custom message screen, the arrow appears to be pointing to the alert's Allow button.

    White X in a gray circle to indicate an incorrect example.

    Don’t draw a visual cue that draws people’s attention to the system alert’s Allow button.