Requesting "Always" Location Access in iOS13 for Geofences

I'm in a similar boat. I'm not sure how you get woken up in the background when entering a monitored region, to ask for 'always' location services to get woken up in the background in the first place. Seems a bit chicken and egg.

I also have concerns for the user experience. Where monitored regions are required for app functionality it does seem backwards to ask people to leave the app to grant permission, and then come back in.

Glad it's not just me that thought this, but the Core Location session thats running right now seems to have shed some light (I guess I should have waited, but I was getting very odd results in Xcode 11 and the simulator, which worried me)

The presenter mentioned that the flow is:

1. Request Always permission via requestAlwaysAuthorization()
2. The user will only be given the option to either accept While in Use, or Allow Once. But the system will remember that you requested Always.
3. If the user accepts While In Use - the presenter said the didChangeAuthorization delegate will actually come back with a status of .always. Your app is in a provisional status where CoreLocation tells it that it has Always permission, even though the user hasnt yet been prompted for that.
4. When the user hits one of your geofences, they will then be asked if they want to grant your Always permission (so they understand the context of where you were asking for), and if they accept, your event will be delivered as usual.

This flow sounds fine, but its not currently whats happening in the Simulator and Xcode 11. In the simulator, even when asking for Always permission via requestAlwaysAuthorization(), the delegate callback from point 3 comes back with just .authorizedWhenInUse. Also CLLocationManager.authorizationStatus() comes back with .authorizedWhenInUse.

Hopefully this is a beta bug, and maybe anyone can confirm that the intention that for step 3, both the didChangeAuthorization delegate method, and CLLocationManager.authorizationStatus() will come back with .always while the app is in provisional Always state?

The docs and the talk also give the impression that after calling `requestWhenInUseAuthorization`, if the user grants When In Use, you should be able to call `requestAlwaysAuthorization` to incrementally prompt the user for Always without relying on "provisional" Always and a prompt outside of the app. However, this doesn't seem to work in the beta. Did you have the same understanding? Are you seeing this behavior as well?

Yeah, I'm seeing that if you call requestWhenInUseAuthorization() and then subsequently call requestAlwaysAuthorization(), nothing happens on the subsequent call. Even though its always been the case that calling requestAlwaysAuthorization() after the initial call for whenInUse should ask the user to upgrade.

I dont think they mentioned this in the talk though? And the Apple documentation pages for these methods don't seem to have changed at all according to the diffs - so I'm not sure what the expected flow is. Given that the documentation hasnt changed though, and that Apple have always made it clear that you should only request what you need - it doesnt sound right to me that the subsequent call to requestAlwaysAuthorization() does nothing. Seems like either the behaviour or the documentation is wrong.

I'd file a radar! I already have done for my issue, but the more the merrier!

(as a side note, given the new flow where requestAlwaysAuthorization() presents the same UI as requestWhenInUseAuthorization(), and given that Apple seem to want to prompt the user for the Always location while in the background to give the user extra context of what's happening - I'm not sure if there's even any point in the two methods being different anymore?)

Yes that's what I didn't understand when they said that in the talk as when I tried it on Tuesday I was getting back whenInUse authorization even though I asked for always and the guy said you should get back temporary always.

From the talk I wasn't too sure of 4 in practise, it sounded like that if when you hit one of the regions you are monitoring iOS may not ask the user for permission if it isn't an optimal time... who knows what the logic is for this?

I am very concerned the user experience for apps which do require always authorization is a bit pants now to say the least. If you app says it will do something for the user in the background and it doesn't because iOS hasn't gotten around to asking them for always permission and the delegate doesn't get the first few notifications through because of the delay this isn't a great first impression for the user of your app.

I don't like Apple second guessing developers. If there is a reason we want to ask for always authorization then let us, and if we get user push back then fine. But its worse not being able to do something because of Apple imposed limitations on what they believe is right. Why have two methods askForAlways and askForWhenInUse when they do the same thing now?

"I am very concerned the user experience for apps which do require always authorization is a bit pants now to say the least. If you app says it will do something for the user in the background and it doesn't because iOS hasn't gotten around to asking them for always permission and the delegate doesn't get the first few notifications through because of the delay this isn't a great first impression for the user of your app."

I 100% agree with this. I think its likely our users will blame our apps for not working when we have no control over the situation. And the user has no ability to understand or control when they will be prompted - they have to rely on the "magic" of this extra prompt choosing to appear at some time when they enter the geofence (and might not even understand why it is even appearing - as far as they're concerned they already gave permisison with the initial prompt).

This is aside from the fact that the initial prompt is now confusing (the user may think "why is the app only asking for permission while being used, when I'm asking it to notify me when I enter an geofence, do I now have to keep the app open?")

I suspect that we will end up with at least a few bad reviews appearing from this if users think its our apps that arent working. The presenter in the WWDC talk mentioned that it may result in at least the first few events being missed, but suggested this was an ok trade off - I disagree with this as we've told the user we have the geofences set, and they have no reason to believe they shouldnt be working.

Just want to say that I aggree 100% with what has been said here. On the current (first) beta, the delegate function reports "when in use" although the app should be in the provisional state after calling requestAlwaysAuthorization. Furthermore, I don't unterstand how "remind me at a location" services should work now, if iOS is blocking delivery until it decides to ask the user for permission. If this is really the way Apple wants to go, then this permission popup should be a local notification that is sent to the user when the region is entered, even if he has the phone in his pocket. Waiting for the user to be on the home screen defeats the pupose of the API.

Wondering if any of you folks have discovered any fixes yet? My App also relies on Geofences and I setup two iOS 13 phones with the app that asked permission, I gave it the "While In Use" (vs One Time or None) and after a day my application has not gotten any fence crossings reported from the OS. Which the user is going to blame me the developer, not Apple since the function that is failing from a user's perspective is my application.

There’s no movement on my developer feedback assistant bug report (replacement for radar), and it has a note: “Recent Similar Reports:Less than 10” So if it’s important to you I’d probably recommend posting a bug in the developer feedback assistant https://feedbackassistant.apple.com/welcome

51475789 bug (temporary Always authorization given as whenInUse) still exists in Beta 2.

The bigger UX issue also still exists.

Thanks for checking - I hadn’t downloaded beta 2 yet

FYI my feedback bug report is FB6120856 and I did include a sample project too. I can only assume that they _must_ already know about this bug seeing as the provisional permission was such a big part of the wwdc talk, but hopefully the report helps if not.

And yes I really hope that - if we assume this idea of the extra prompt won’t be reverted - the permission prompt is at least delivered as a local notification when the user enters the geofence, and not just when the user next happens unlock, missing the geofence.

Also in the same boat. The description of jdelaune on the user experience is exactly pointing the disappointment that can only occur in the user experience. When your app is based on Always you end up with the following:

• The user thinks the app is working, while it’s not and this leads to disappointment. After download from the App Store and install this looks all good. I even believe some may not notice the fact that there is a "While In Use" instead of "Always" presented especially if they have heard about the app and are eager to try it. Then they will put the app in their pocket or leave the app and at the next opening it will be "this does not work" . Or they will simply not leave the app!!!!
• The user has to accept twice an authorization and the second time without the context of the application. Usually a user makes an App Store download with an intent that’s very clear, and it can not be futhfilled with what Apple is offering. If the second authorization appears at a non ideal time (like user is on the bike and should not look at their phone), it may get a totally wrong attention.
• Finally, from what I get from the WWDC video I do not see a way for the user to declare their intent at a sooner than when iOS decides about it. If I am correct the speaker is even using words like "it will appears at a good time" and then speak about how a location even is intercepted and not delivered because it requires the second approval. But in our tries we never saw it.

I can't believe it can stays this way with so many imprecisions in behaviors and UX flaws.

Hi there,

I'm also working on an app for which the user experience depends heavily on Always On location authorization. I agree with most of the points that have been exposed here. Even though the intentions are genuinely good, this could kill a lot of use cases right from the first run experience.

It looks like iOS 13 Beta 3 finally implements the changes advertised by Apple, and I must say the user experience regarding the new authorization flow makes absolutely no sense.

During my testing I've noticed that:

1. the app now receives "Always" when the user selects "When in use" when prompted in the app (what's called "Provisional always location")

2. the app does not receive "Always" if the user selects "Once" when prompted

3. the system only prompts the user to go to "proper always" when the phone is unlocked (no notification, that is)

4. the only way the user can give the app Always permissions without being prompted first is via the phone's Settings>Privacy>Location>Your App (could not even see it in Settings>Your App any more) – and we have no way to deep-link to this Settings screen from within an app AFAIK.

In my opinion these changes are very detrimental to the user experience in many use cases, especially regarding first run experience.

If your app depends on background location for anything useful to the user, it's basically useless until the system decides to present the "permission upgrade" modal. It works only if the user keeps the phone unlocked and active when the location events begin, which is exactly the opposite of what users expect for background location features.

Well please do file feedback with Apple. Although sadly it looks like this flow will not change and our feedback is falling on deaf ears.

Annoying if you go to the Settings screen for you app 'provisional always' shows as 'Always', its only when the user drills in to change it do they see that they really have 'While Using the App' permission granted. Can't even easily ask users to go in and change it manually as they will think they have granted Always looking at that.

'Provisional always' is one of the bizarrest concepts Apple could have cooked up. Especially when they don't even expose the real state to us developers.

I just filed feedback: https://feedbackassistant.apple.com/feedback/6771758

In iOS 13, not possible to request always authorization as upgrade to when in use authorization (only "provisional" always authorization works)

In iOS 13 we are under the impression that, in addition to the new "provisional" always authorization, it should still be possible to directly prompt users for always authorization, assuming that they had granted when in use authorization first.

Expected behavior:

1. Prompt for when in use.

2. User sees prompt immediately and grants when in use.

3. Later in the app lifecycle, prompt for always.

4. User sees prompt immediately and is able to grant always.

However, we have not seen this work in iOS 13 betas 1 through 4 so far.

Actual behavior: The second prompt to upgrade to always never appears.

The docs suggest that this is still possible: https://developer.apple.com/documentation/corelocation/cllocationmanager/1620551-requestalwaysauthorization?changes=latest_minor

"If your app has never requested always authorization and its current authorization status is CLAuthorizationStatus.authorizedWhenInUse, you may call this method one time to try and change your app's authorization status to CLAuthorizationStatus.authorizedAlways."

This WWDC 2019 video also suggests that this is still possible: https://developer.apple.com/videos/play/wwdc2019/705/

At 6:57, "…or, you can request when in use authorization first, then, at some later point, when the user interacts with a feature of the app that warrants it, seek always authorization later."

--

We think that this lets developers create more predictable experiences than the new "provisional" always flow, and we've seen a few other developers express concern on the forums: https://forums.developer.apple.com/thread/117256

More importantly, in keeping with the spirit of other changes in iOS 13, we also think that it gives end users more transparency than the "provisional" always flow, as it lets developers provide additional context in-app before the prompt is displayed (e.g., a screen in an onboarding with illustrations, and not just the plist string displayed in the prompt).