Request user permission to access restricted resources by providing a purpose string that explains why you need the access.
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:
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.
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
NSLocation key. Modify your
Info file using the property list editor built into Xcode:
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
NSContacts key be present:
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, like HomeKit, 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 acess 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:
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.