-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reconsider background tracking mode impl for iOS13 #136
Comments
@js thanks for the heads up, we've been tracking this and hope to have a fix in the SDK and Maps before iOS 13 is in public beta. |
The public release of iOS 13 is (probably) not many weeks away, any updates on this? |
iOS 13 is most likely being released to the public in a week, yet I have seen no intention from Mapbox to resolve this issue? @alfwatt Could you please give us any indication as to what your plans are to resolve this issue please? It will have a pretty big negative impact on our app, and indirectly on mapbox and the (lack of) data you'll collect. |
@js We've been tracking the iOS 13 changes closely and have been working on an update to our telemetry collection practices. We'll provide an update as soon as possible, as we understand your concern and agree it's an important issue. |
@alfwatt iOS 13 will be publicly released on September 19th, in seven days, please give us ample time to submit and get our updates reviewed with your updated SDK. |
@js sorry we don't have a fix ready, we're discussing with our execs how to proceed. What we've seen in our testing is that the prompt in iOS 13.1 doesn't display all the locations which are sent to the application but only the significant location change notifications, e.g. here's the 3-day alert for our testing app compared with the last two days worth of collection on my device: |
@alfwatt Yes this matches my observations as well. But the issue here isn't really the granularity of the data collected as such, but entirely about the fact that an app will now explicitly make the user aware that it's collecting data in the background (which in itself is probably good). In an app where background location tracking is entirely context-based (such as a workout app) and opt-in through an action (such as starting a workout) then the appearance of a dialog such as the above when the user didn't expect it will almost certainly cause the user to revoke the background location permission, which is bad news for the app as it no longer gets background access and we've essentially betrayed the users trust here (!), but also bad news for mapbox and your data collection. |
As I'm digging into what exactly it is mapbox is doing here, I'm not sure where I got 3000m from, it's actually when leaving a 300m radius and then it attempts to track it at most for five minutes it seems? Am I reading this and understanding that intention correctly? The problem is that it keeps tracking the location beyond these two, a casual read through the implementation seems to point at significant location monitoring and visit monitoring is still active after the five minute limit. Please correct me if I misunderstand anything here, I'd very much like to understand Here's what seems to be happening, please correct me in what I misunderstand:
Assuming I read everything correctly there's a few issues in the above imho: Number two above has some issues when a new location arrives, which will happen (?) since the location manager is started again when exiting the region:
Apart from the timeout issue mentioned in number 3, it doesn't actually stop all the location monitoring that was started only regular location updates, region moniting, visit monitoring and significant location monitoring is still active. Seems like it should be calling |
I can confirm - at least for our App - that disabling the Mapbox Metrics (via the UserDefault |
@ChristianSteffens if you app has either If your app does not use background location you can remove those keys from your |
🤔, i.e. the mere existence of these two (2) keys will result in background location tracking? Even if the App doesn't have the necessary permissions? |
Beware that this will cause errors if I'm not mistaken. Because Apple identifies that MapBox has code references to the "Always" permission you'll receive a warning email from app store connect informing you that you should indeed provide these strings. The email will read as follows:
So you either have a warning and complications with Apple or provide the necessary strings and have MapBox attempting to pull in the unwanted location updates. The only logical solution to me appears to have control over what permission MapBox-Events uses and when...or fork and throw out all code references to the always permission. |
It's February '20. This issue is a few months old by now, and in the mean time NYT published their opinion piece, that moved the needle some more towards general suspicion of those three-day-pop-ups. Have there been any developments for the Mapbox SDK, or is there a sanctioned way of disabling the region monitoring? |
@epologee please check out the latest information in the readme, Release 0.10.0 contains some changes to the region monitoring for iOS 13: https://github.com/mapbox/mapbox-events-ios#-foreground-and-background-location-collection |
Hi Alf, thanks for the reply. I still think this issue is a valid open one. @JustinGanzer already mentioned that section of the readme, above. However the suggestion to remove keys from the Plist to fix this, does not apply.
The Mapbox SDK is not actively used in the background. It's an entirely non-map related feature in the app. I know that the terms state that we should not limit the data that the Mapbox SDK sends "back home", however there's no requirement to do so in the background, or at least, I can't spot it directly. If I'm mistaken here, please let me know. |
@epologee Their terms are kept short and readable, though it does say
At least that is how it sounds to me and as such leaves no room for interpretation of "no requirement to do so in background" anywhere. However the sdk is open to anyone and you're not using their service if you're hosting your own map data server or don't pull any map data from mapbox because you're not using it display a map at all? (Though I wonder what it is one does with mapbox with no maps). Those are the only two solutions I see here. |
If you use the navigator SDK which includes this one:
So you cannot simply fork it and disable this. If you need a license free navigation SDK fork an older version or use one of the existing forks. |
@JustinGanzer we're looking at the issue with the |
iOS 13 changes the way background location permissions work.
If I understand the current implementation correctly this is how the mapbox-events-ios SDK works
** 5 minutes has passed
** OR when the user leaves a 3km wide geofence
in iOS13 the app can still ask for always access and either always or while in use is granted, but it'll still appear as authorizedAlways to the app until location is actually requested while in the background, at which point (or perhaps even sometime later "when convinient") the OS will ask the user if they want to allow background location updates.
Seems to be this will leave a surprise for many mapbox users. Let's say an fictional hiking app asks for
requestAlwaysAuthorization
or has done so at a previous time, but it won't actually starts it's own CLLocationManager in the background until the users decides to start a hike through some interaction in the app.However, since the app now seemingly has
.authorizedAlways
mapbox-event-sdk will start its background location tracker and when the app is in the background the user will get asked if they want to allow background location updates, completely out of context as they've only intended to allow background location access when they've actually started a hike.https://developer.apple.com/videos/play/wwdc2019/705/
The text was updated successfully, but these errors were encountered: