{
	"id": "de3f42ca-536e-4485-87a4-1cd1c2062e33",
	"created_at": "2026-04-06T00:10:03.848122Z",
	"updated_at": "2026-04-10T03:20:44.254717Z",
	"deleted_at": null,
	"sha1_hash": "bfab93a5d62c44243ab5df3bbae848e3b491e592",
	"title": "Requesting authorization to use location services | Apple Developer Documentation",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 53080,
	"plain_text": "Requesting authorization to use location services | Apple Developer\r\nDocumentation\r\nBy Make authorization requests and respond to status changes\r\nArchived: 2026-04-05 17:20:50 UTC\r\nOverview\r\nLocation data is sensitive information, and the use of location data has privacy implications for the people who\r\nuse your app. To ensure that people maintain control over their own information, the system prevents apps from\r\nusing location data until they obtain authorization to do so. This authorization process involves a one-time\r\ninterruption, during which the system prompts the device owner to grant or deny your app’s request for location\r\ndata. After the initial interruption, the system stores your app’s authorization status and doesn’t prompt again.\r\nTo help people understand why you need location data, make authorization requests only when someone engages\r\na part of your app that requires that data. Making the request immediately before it’s needed increases the\r\nlikelihood of the person granting the request. If you make a request immediately at app launch, or in a part of your\r\napp that doesn’t clearly use location data, the person might misinterpret your intent and deny the request.\r\nChoose the access level you need\r\nBefore you place an authorization request, choose the level of access your app needs. Core Location supports two\r\nauthorization levels:\r\nWhen in Use authorization makes location updates available only when someone uses your app. This\r\nauthorization is the preferred choice, because it has better privacy and battery life implications.\r\nAlways authorization makes location updates available at any time, and lets the system launch your app\r\nquietly to handle some updates. Request this access level only when necessary on other platforms. For\r\nexample, request it if your app delivers time-sensitive responses to location changes automatically, or\r\nimplements a location push service app extension. This access level isn’t available when running in\r\nvisionOS.\r\nThe definition of when an app is in use depends on the platform:\r\nOn iOS, an app is in use when it’s in the foreground and for a short time when it transitions from the\r\nforeground to the background. If you enable background location updates, an app with When in Use\r\nauthorization continues to run in the background when location services are active; if location services\r\naren’t running, the normal suspension rules apply. If the system terminates the app or the app isn’t running,\r\nthe system doesn’t launch an app with When in Use authorization to deliver new updates; it does launch an\r\napp with Always authorization for some types of location updates.\r\nhttps://developer.apple.com/documentation/corelocation/requesting_authorization_for_location_services\r\nPage 1 of 3\n\nOn macOS, When in Use and Always authorizations are functionally equivalent. Because macOS apps\r\ncontinue to run in the background after their initial launch, they are always in use. If you create your Mac\r\napp using Mac Catalyst, request authorization based on the needs of your iOS app.\r\nOn watchOS, complications can receive location updates, but the watchOS app must run at least once so it\r\ncan request authorization to access location data. If an app’s complication is on the current watch face, the\r\nsystem treats that complication as if it’s in use and delivers location updates to it. The system doesn’t\r\nlaunch watchOS apps, even if they have Always access.\r\nOn visionOS, an app is in use when someone is looking at it, and for a short time after the person stops\r\nlooking at it.\r\nRegardless of which access level you choose, you can start any location services available on the current device\r\nand achieve the same results. Access levels primarily determine how your app receives updates when it isn’t\r\nrunning. The following table summarizes the differences between access levels.\r\nCapability When in Use Always\r\nSupported platforms All All platforms except tvOS and visionOS\r\nSupported location services All All\r\nLaunches a terminated app\r\nautomatically\r\nNo. The user must\r\nlaunch the app.\r\nYes for significant location change, visits, and\r\nregion monitoring services; no for others\r\nFor information about how to handle location updates in the background, see Handling location updates in the\r\nbackground.\r\nProvide descriptions of how you use location services\r\nThe first time you make an authorization request, the system displays an alert asking the person to grant or deny\r\nthe request. The alert includes a usage description string that explains why you want access to location data. You\r\nprovide this string in your app’s Information Property List and use it to inform people about how your app uses\r\nlocation data.\r\nCore Location supports different usage strings for each access level. You must include a usage description string\r\nfor When in Use access. If your app supports Always access, provide an additional string explaining why you\r\nwant the elevated privileges. The following table lists the keys to include in your app’s Information Property List\r\nand when to include them.\r\nhttps://developer.apple.com/documentation/corelocation/requesting_authorization_for_location_services\r\nPage 2 of 3\n\nAdd all usage description keys to your app’s Information Property List before you make any authorization\r\nrequests. Authorization requests fail immediately if the required keys aren’t present.\r\nBefore you start any location services, check your app’s current authorization status and place an authorization\r\nrequest if needed. You can get your app’s current authorization from the authorizationStatus property of your\r\nlocation-manager object. However, a newly configured CLLocationManager object also reports your app’s current\r\nauthorization status to its delegate’s locationManagerDidChangeAuthorization(_:) method automatically. You\r\nmight use that method to place an authorization request when the current status is CLAuthorizationStatus.not\r\nDetermined . In the following example, the delegate method enables or disables location features when the status\r\nis known and requests authorization when the status is undetermined.\r\nfunc locationManagerDidChangeAuthorization(_ manager: CLLocationManager) {\r\n switch manager.authorizationStatus {\r\n case .authorizedWhenInUse: // Location services are available.\r\n enableLocationFeatures()\r\n break\r\n \r\n case .restricted, .denied: // Location services currently unavailable.\r\n disableLocationFeatures()\r\n break\r\n \r\n case .notDetermined: // Authorization not determined yet.\r\n manager.requestWhenInUseAuthorization()\r\n break\r\n \r\n default:\r\n break\r\n }\r\n}\r\nThe locationManagerDidChangeAuthorization(_:) method offers a central place to process any authorization-related changes. People can change your app’s authorization status at any time in system settings. If your app is\r\nrunning when the change happens, each of your app’s CLLocationManager objects reports the change to that\r\ndelegate method. The location manager also reports your app’s current authorization at other times. For example,\r\nthe location manager also calls the method when a suspended iOS app starts running again.\r\nSource: https://developer.apple.com/documentation/corelocation/requesting_authorization_for_location_services\r\nhttps://developer.apple.com/documentation/corelocation/requesting_authorization_for_location_services\r\nPage 3 of 3",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://developer.apple.com/documentation/corelocation/requesting_authorization_for_location_services"
	],
	"report_names": [
		"requesting_authorization_for_location_services"
	],
	"threat_actors": [],
	"ts_created_at": 1775434203,
	"ts_updated_at": 1775791244,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/bfab93a5d62c44243ab5df3bbae848e3b491e592.pdf",
		"text": "https://archive.orkl.eu/bfab93a5d62c44243ab5df3bbae848e3b491e592.txt",
		"img": "https://archive.orkl.eu/bfab93a5d62c44243ab5df3bbae848e3b491e592.jpg"
	}
}