Post not yet marked as solved
Thanks for checking - I hadn’t downloaded beta 2 yetFYI 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.
Post not yet marked as solved
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
Post not yet marked as solved
"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.
Post not yet marked as solved
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?)
Post not yet marked as solved
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:Request Always permission via requestAlwaysAuthorization()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.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.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?
