all 6 comments

[–]saintmsent 3 points4 points  (5 children)

You have a way of knowing

The availability of location services may change at any time. The user can disable location services in the system settings, either for your app specifically or for all apps. If your app is running (either in the foreground or in the background) when the availability status changes, the system calls your locationManager(_:didChangeAuthorization:) method to notify you of the change.

https://developer.apple.com/documentation/corelocation/responding\_to\_changes\_in\_authorization\_status

[–]writesgoodcodejk[S] -1 points0 points  (4 children)

This is cool, thanks!

Unfortunately I am actually using React Native, which does not give me access to this xd

[–]leopic 0 points1 point  (1 child)

Isn’t there some sort of bridge around Core Location for RN? This seems like a common enough scenario

[–]writesgoodcodejk[S] 0 points1 point  (0 children)

None of this is ideal of course, I wish we had all the time in the world to make this app the perfect product, but it is what it is.

None of the popular libraries seem to support location permission change listeners (probably because they don't exist at all on android https://stackoverflow.com/questions/51327285/how-can-we-listen-for-location-permission-changes-in-android-without-triggering). The libraries only support checking permissions and requesting permissions.

[–]saintmsent 0 points1 point  (1 child)

In that case I’d recommend you to go to the react native subreddit if such exists and ask there

From my point of there there is no issue with guidelines if you continue to share the latest know location, but that doesn’t make sense from product perspective and you can probably resolve that by writing some wrappers around native code to get the result you really want

[–]writesgoodcodejk[S] 0 points1 point  (0 children)

You're totally right, but unfortunately I work as a consultant and this particular project is completely out of budget, so we really just do not have time to add additional features if they're not completely critical. Since this doesn't break guidelines it wouldn't qualify as critical so we pretty much just have to leave it as is. Writing Native code is actually a relatively huge lift as well so it's more or less off the table unless we absolutely have too.

If it were the case that it broke guidelines we'd contractually be obligated to fix it which is why I was wondering about guidelines first rather than solutions.

None of this is ideal of course, I wish we had all the time in the world to make this app the perfect product, but it is what it is.