As per the WWDC video, https://developer.apple.com/videos/play/wwdc2019/705/, when you ask for "AlwaysAuthorization" permission you will see only "When In Use, Once and Don't allow". Even if you tap on "When In Use", the delegate call back will come back as kCLAuthorizationStatusAuthorizedAlways. This is working as expected. But is there a way to find out that the request is still provisional or actually-always-allow?
There is no enum associated to this permission. The only allowed enums are:
kCLAuthorizationStatusNotDetermined, kCLAuthorizationStatusDenied, kCLAuthorizationStatusAuthorizedAlways, kCLAuthorizationStatusAuthorizedWhenInUse
Because I want to show an alert as soon as user grants the "While In Use" permission, to tell them that the app will only work if you provide "Always Allow" via system preferences and I can navigate them to the system settings page of my app via a tap, just like how Zenly is doing it: https://www.macrumors.com/2019/08/16/app-developers-tracking-restrictions-ios-13/
You can check if you're getting location updates in the background for more than 10 seconds after the application gets in the background. If yes, then you have the permanent Allow Always. If not, then you have the provisional Allow Always (or any other authorization that you can check explicitly).
Related
I am experiencing unexpected behavior in the iOS location authorization process. Here are my steps including a screen-grab
I request "Always" authorization on iOS 13.
I only grant the app the "Allow Once" authorization, which grants the user a temporary "When In Use" authorization.
I request "Always" authorization again.
This time, no authorization prompt is shown and the didChangeAuthorization delegate method gives .authorizedAlways
However, when I look at the authorization status in the Settings app, it says "Ask Next Time", which corresponds to an authorization status of .notDetermined.
My questions:
Why is there no second prompt when I request "Always" authorization a second time?
Why does the delegate method give the .authorizedAlways status without me actually giving that authorization?
Why does the Settings app indicate that the authorization status is .notDetermined when the delegate method said it was .authorizedAlways.
I feel like this is a bug in iOS, but I might also just be misunderstanding the way the authorization flows should work. What do you think?
I haven't been able to test this on a real device with iOS13, so I don't know if it's maybe just a problem in the simulator?
The user has already been asked for a location permission in this session; they selected "allow once". If iOS prompted them a second time it would be annoying and confusing.
Your app is upgraded to "provisional always" state after the second request; it is allowed to think that it has always so that any permission checking logic you may have built won't keep asking the user to go to settings or whatever. Since the app doesn't really have always there is no impact to user privacy, so there is no harm in reporting "always"
The settings app reflects the user's actual choice which is "ask me again next time".
The WWDC video that #Don suggested in the comments explains about provisional always permission and its purpose in satisfying app permissions logic.
Why is there no second prompt when I request "Always" authorization a second time?
In iOS 13.0, just requesting “always” permission a second time does not qualify as the “event” to trigger the prompt to the user. You actually have to to perform the action that requires “always”.
For example, I request always, and got the “when in use” prompt. I turned on significant change service, but did not receive prompt for always. Only when I hopped in my car and started to drive away did the significant change actually trigger the “always” prompt.
In WWDC 2020 video What's new in location, they describe a change introduced in iOS 13.4. You can ask for “when in use” and assuming the user granted it, you can ask for “always” and get the second alert (this time asking if the user would like to upgrade to “always” or not). You just need both “Privacy - Location When In Use Usage Description” and the “Privacy - Location Always and When In Use Usage Description” usage strings.
On iOS if you never asked user for notification permissions then this option will not appear in device settings for your application.
I wonder is there a way make this option appear in the settings in 'Denied' state without prompting a notificatoin permissions request so user can enable this option later by himself?
Thanks
I would say, that is not permitted. If it were possible to change authorizationStatus programmatically, or set it to some default state, then you would able to set it to 'authorized' state too, without asking user about it.
My app can have two level of LocationHandler status. First, I launch requestWhenInUseAuthorization and then, if the user activates some specific features, I launch requestAlwaysAuthorization.
I need to be notified if user refuses the requestAlwaysAuthorization to let him know the feature won't work as expected. The problem is that in this case didChangeAuthorizationStatus is not called because the authorization status stays the same (it was AuthorizedWhenInUse and it's still AuthorizedWhenInUse).
Do you have any idea how I could be notified if user refuses AuthorizedAlways after accepting AuthorizedWhenInUse ?
since iOS 10 or so it is no longer possible to call requestAlwaysAuthorization() after you have called requestWhenInUseAuthorization() even if the user accepted when-in-use.
in prior versions (at least iOS8) you could "step up" the authorization and ask for always-authorization after the user accepted when-in-use. This is no longer possible.
best thing to do is check CLLocationManager.authorizationStatus()
once in a while and show a dialog pointing the user to the right settings page with UIApplicationOpenSettingsURLString
I just finished developing an app that interacts with the Beacons and User location.
I ask for locationManager the requestAlwaysAuthorization permission and I have added in the plist NSLocationAlwaysUsageDescription property with my description; everything works perfectly!!!
I realized that: if a user does not accept the requested permission, iOS disables localization always and when in use, making very limited the use of the app.
I wish that if a user refuses the requestAlwaysAuthorization automatically being asked requestWhenInUseAuthorization permission!
This is possible with some native method or I have to handle the request for another permission?
Thanks to all!
EDIT:
How do apps like Shazam or Facebook to have three choices "Never," "When in use" and "Always" in the location settings?
Surely there is a way to present them to the user?!?!
You can't do that. When in doubt, please always head to the Apple documentation.
https://developer.apple.com/library/ios/documentation/CoreLocation/Reference/CLLocationManager_Class/index.html#//apple_ref/occ/instm/CLLocationManager/requestAlwaysAuthorization
After requestAlwaysAuthorization is finished (the user accepted/denied), the status is changed to ether kCLAuthorizationStatusDenied or kCLAuthorizationStatusAuthorized(or some other, doesn't matter).
Furthermore, both requestAlwaysAuthorization and requestWhenInUseAuthorization both have such logic (described in the documentation)
If the current authorization status is anything other than kCLAuthorizationStatusNotDetermined, this method does nothing and does not call the locationManager:didChangeAuthorizationStatus: method.`
If the user denies the requestAlwaysAuthorization the status is changed to kCLAuthorizationStatusDenied and both request authorizations will be ignored in future.
When the user launches the app for the first time and attempts to login, they are prompted with the iOS dialog - "Turn On Location Services".
I need to capture when the user clicks "cancel". Is there a Notification sent? If so, what is its name? I've been unable to locate it.
The CLAUthorizationStatus is kCLAuthorizationDenied when Location Services are Disabled OR the user clicked "Don't allow". When the user clicks "Cancel", it does not fire the authorizationChange event. When user clicks "Cancel", the app just hangs.
Short answer: You can't catch that notification. You can infer about the user choice and act consequently by using CLLocationManager methods (the longer answer below).
Longer answer:
Firstly, welcome on Stack Overflow. Before kindly posing your question, and trying to be collaborative with people that are here to help, it's a good idea to search if somebody else previously posed the same question.
A brief search gave (just to mention some of them):
How to handle “Cancel” button on Alert pop up for Location services
How to get location services to reprompt the user for location permission if they accidentally refused it?
locationManager:didFailWithError: not called if user Location Services are off
How to prompt user to turn on Location Services…again
How can I prompt the user to turn on location services after user has denied their use
How to ask permission from user for second time to allow to access the current location?
Now, let's try to summarize them all, starting from iOS docs:
If your app relies on location services to function properly, you should include the UIRequiredDeviceCapabilities key in the app’s Info.plist file. You use this key to specify the location services that must be present in order for your app to run. The App Store uses the information in this key from preventing users from downloading apps to devices that do not contain the listed features.
Important: If your app uses location services but is able to operate successfully without them, do not include the corresponding strings in the UIRequiredDeviceCapabilities key.
So, if your app really needs to access the user's position you should add location-services and eventually gps to UIRequiredDeviceCapabilities.
Then, somewhere in your code - when needed, you have to check if the location services are enabled.
[CLLocationManager locationServicesEnabled]
they may be disallowed for three reasons:
The user can disable location services in the Settings app.
The user can deny location services for a specific app.
The device might be in Airplane mode and unable to power up the necessary hardware.
You are interested in the second case: the user refused to allow your app to use the location services.
Again, from the docs:
Important: In addition to hardware not being available, the user has the option of denying an application’s access to location service data. During its initial uses by an application, the Core Location framework prompts the user to confirm that using the location service is acceptable. If the user denies the request, the CLLocationManager object reports an appropriate error to its delegate during future requests. You can also check the application’s explicit authorization status using the authorizationStatus method.
[CLLocationManager authorizationStatus]
That may return:
kCLAuthorizationStatusNotDetermined if the user has not yet made a choice regarding whether this application can use location services.
kCLAuthorizationStatusRestricted this application is not authorized to use location services. The user cannot change this application’s status, possibly due to active restrictions such as parental controls being in place.
kCLAuthorizationStatusDenied The user explicitly denied the use of location services for this application or location services are currently disabled in Settings.
kCLAuthorizationStatusAuthorized This application is authorized to use location services.
If[CLLocationManager locationServicesEnabled] returns NO and you attempt to start location services anyway (i.e. calling [locationManager startUpdatingLocation]), the system prompts the user to confirm whether location services should be re-enabled. Given that location services are very likely to be disabled on purpose, the user might not welcome this prompt.
I suppose you know, and did all the previous steps (I'm only sure you checked the authorizationStatus). You refused to show us the significant code of your app so I can only suppose the overall logic behind. Now you said your app hangs. This should be because you didn't catch the error properly? Catching the error is the way to re-prompt the user, if you wish.
After calling [locationManager startUpdatingLocation], if not authorized, your delegate should define a locationManager:didFailWithError: in order to catch the kCLErrorDenied.
- (void)locationManager:(CLLocationManager *)manager didFailWithError:(NSError *)error
You may show, at this point, a UIAlert to insist asking the user to give you access to its position, or trigger a change in the UI or whatever you like.
Final notes
I hope you understand why I was asking for the code: the reason was to offer you an alternative solution instead of reply "You can't catch the 'Cancel' notification".
If this answer does not satisfy your question please elaborate why you need to catch the pushing of the "Cancel"/"Do not allow" button, so we can provide alternatives.
Clearly my advice is to not annoy people to death by continuously ask them for enabling location services if they don't want.
Post scriptum: Maybe that the answer looks pedantic and obvious in certain parts if not all to you, but we are here to provide answers also for future readers.