Request to Add an “AllowOnce” State to CLLocationManager

Context: Currently in iOS, both “Allow Once” and “While Using the App” location permission decisions yield .authorizedWhenInUse. This conflation prevents apps from knowing whether the user has provided a one-time allowance or a persistent in-use allowance.

Problem Statement

  1. Ambiguous App Behavior: After a user selects “Allow Once,” the app remains in .authorizedWhenInUse, making it appear to the developer as if the user granted a more persistent “While Using” permission.
  2. Poor User Experience: If the user later indicates they want to upgrade to “Always,” developers must guess whether iOS will show another system prompt. This can lead to “dead” button presses or pointless transitions to Settings.
  3. Lack of Transparency: The user’s real intention—“I only trust you this one time”—gets lost in .authorizedWhenInUse with no direct or synchronous detection mechanism.

Why This Wouldn’t Violate SRP

  1. The CLLocationManager’s` Single Responsibility: Manage and expose the user’s current location authorization state.
  2. Adding .authorizedOneTime or an isOneTime property fits neatly into that responsibility. It’s still describing the user’s level of trust for location usage, just with more specificity.
  3. No Overreach: This doesn’t add new logic outside location permissions—it merely refines the existing state definitions for clarity.
  4. Simplifies the Developer Flow: Instead of co-mingling “Allow Once” and “While Using,” the system returns the precise state, letting developers handle transitions more gracefully while abiding by iOS’s privacy rules.

Benefits

  • Improved UX: Developers can present more accurate prompts or guidance. If .authorizedOneTime, the app can immediately direct the user to Settings for a persistent upgrade, rather than futilely calling requestAlwaysAuthorization() again.
  • Less Confusion: A distinctly reported “Allow Once” state eliminates guesswork, polling, or timed approaches that degrade user experience.
  • Consistent with iOS’s Privacy Focus: Providing a read-only flag or status for “One Time” aligns with Apple’s approach to clarity around permissions, without letting apps forcibly bypass user intentions.

If .authorizedOneTime, the app can immediately direct the user to Settings for a persistent upgrade

This sentence here demonstrates exactly why things are how they are. The user's choice of whether give a temporary or long-term authorization is between them and their device. There is no use for an app to know this choice other than try to force the user to act the way the developers think they should.

There would only be confusion or degraded experience if the app insists to have permanent location access rather than having a flow that accepts the users' choices and gracefully adapts. It is only a problem if the app thinks it knows better what the user should choose.

That said, in the new CoreLocation API, CLServiceSession helps you change your approach from request this specific authorization to my app needs this kind of authorization.

When you adopt this new API you will get more feedback, because CLServiceSession and CLServiceSession.Diagnosticswill tell you what the authorization state is and the various reasons it may not be what you want (although not exactly what you are asking for here), while still preserving the user's privacy about their choices.


Argun Tekant /  DTS Engineer / Core Technologies

Request to Add an “AllowOnce” State to CLLocationManager
 
 
Q