Requesting Access to Protected Resources

Provide a purpose string that explains to the user why you need access to protected resources.


Modern devices collect and store a wealth of sensitive information about their users. Many apps rely on this kind of data and the device hardware that generates it to do useful work. For example, a navigation app needs the user’s current GPS coordinates to locate the user on a map. But not all apps need access to all data. The same navigation app doesn’t need the user’s health history, camera interface, or Bluetooth peripherals.

Your app should access only what it needs to do its job. To support this principle, Apple’s operating systems restrict access to protected data and resources by default. Apps can request access on a case-by-case basis, providing an explanation for why they need access. The user decides whether to grant or deny the request.

Provide a Purpose String

The first time your app attempts to access a protected resource, the system prompts the user for permission. In the following example, an iOS app called MyRoute that provides directions generates a prompt requesting access to the user’s location:

Screenshot of a system-generated iOS alert view asking if the app "MyRoute" should be allowed to access location data, including a usage description message from the app’s developer.

If the user grants permission, the system remembers the user’s choice and doesn’t prompt again. If the user denies permission, the access attempt that initiated the prompt and any further attempts fail in a resource-specific way. And for the particular case of access to location data, the user can choose to allow access for only one session by tapping Allow Once.

The system automatically generates the prompt’s title, which includes the name of your app. You supply a message called a purpose string or a usage description—in this case, “Your location is used to provide turn-by-turn directions to your destination”to indicate the reason that your app needs the access. Accurately and concisely explaining to the user why your app needs access to sensitive data, typically in one complete sentence, lets the user make an informed decision and improves the chances that they’ll grant access.

You provide a usage description by setting a string value for a resource-specific key that you add to your app’s Information Property List file. The message shown above, for example, is a string associated with the NSLocationWhenInUseUsageDescription key. Modify your Info.plist file using the property list editor built into Xcode:

Screenshot of an app’s information property list highlighting the added NSLocationWhenInUseUsageDescription key and associated string value that matches the message seen in the previous figure.

App Review checks for the use of protected resources, and rejects apps that contain code accessing those resources without a purpose string. For example, an app accessing contacts might receive the following information from App Review about the requirement that an NSContactsUsageDescription key be present:

ITMS-90683: Missing Purpose String in Info.plist - Your app’s code references
one or more APIs that access sensitive user data. The app’s Info.plist file
should contain a NSContactsUsageDescription key with a user-facing purpose
string explaining clearly and completely why your app needs the data.

To resolve this issue, provide a purpose string that explains why the app needs access to this sensitive information, or remove the code that’s accessing the resource.

Check for Authorization

Many system frameworks that provide access to protected resources have dedicated APIs for checking and requesting authorization to use those resources. This allows you to adjust your app’s behavior depending on the current access it has. For example, if the user denies your app permission to do something, you can remove related elements from your user interface.

Because a user can change authorization at any time using Settings, always check the authorization status of a feature before accessing it. In cases without a dedicated API, be prepared to gracefully handle access failures.

Reset Authorization Access

When your app attempts to access a protected resource after its first attempt, the system remembers the user’s permission choice and doesn’t prompt again. To prompt the user again, you must reset access to these resources on your device or system.

To reset permission access to a protected resource in iOS apps, tap Settings > General > Reset > Reset Location & Privacy on your device.

To reset permissions for a particular service in macOS apps, run the tccutil reset <service name> command in Terminal. For example, to reset all permissions for AppleEvents, type:

$ tccutil reset AppleEvents

This command resets authorization access for all apps using the protected resource. You can similarly specify AddressBook, Calendar, Reminders, or other services to reset them individually.