Location Permissions in iOS 11 and avoiding the Blue Bar of Shame
UPDATE: As of beta release 5 it appears you can void the blue bar by polling location in the background. Awaiting official changes docs from Apple.
iOS 11 includes a few updates that are probably of interest to a lot of geo-folks out there:
- A flashing blue status bar anytime an app is collecting your location data in the background.
- Updated locations permissions that always give the user the ability to choose only to share location while using the app (*cough uber*)
For consumers, these are pretty great new privacy features implemented by Apple. We’ll ignore the possible mote digging motivations for now. But for developers who use location for good and not for evil, these features are worth a deeper look. At Set, we currently use location to help tick our models forward, so we were interested in learning more about the status bar and what drives its little blue flash as well as the changes to the permissions dialogs provided in iOS 11. Here’s what we found.
Applications that run with the GPS always on
This is going to be the case with any app that runs GPS all the time. One example we found out there was Moves, an app that makes a pretty clear case for getting persistent access to your data. However, no matter how pure the intentions are, the Blue Bar of Shame is intrusive enough (it is visible even when another app is open) that probably no app will be able to run with it always-on.
In the SetSDK, we were using an open GPS request to help keep the SDK alive and learning. We were able to run a low-precision GPS request that would be very gentle on the battery and buy us time to run our algorithms. But that all changed the day the blue bar was released in iOS 11!
Moving off of always-on GPS sensors was something we have had on our backlog for a while now, so Apple’s changes have made us ramp up on that enhancement. We think overall it’s going to be good for all apps and hopefully make people even less weary of bad actors, since they can always monitor who is up to no good. We’re happy to see that. Along the way, we tested out which APIs were available to Background Location that didn’t cause the Blue Bar. Here is what we found:
Applications using Significant Changes and Geofences
We’ve run a couple of experiments with the Significant Changes API and the Geofences API. After installing apps that use either of those APIs, Aaron, Carson, Sander and I have individually monitored our phones for the Blue Bar of death. The result, we didn’t see it turn blue ever. This helps verify the hypothesis that Apple is using the blue bar to steer more developers toward their APIs over using the raw data.
Applications using Visits API
The Visits API is a really interesting API that Apple provides. The API tries to establish places and then will tell your app when a user arrives or departs those places. In our previous experiments with the API we didn’t love the resolution or timeliness of the API, but the API doesn’t trigger the Blue Bar of death.
What’s next for the “Always On” permission?
You may have heard that Apple now forces apps to allow users to select any of 3 levels of location permission in apps. Always on, Only while using app, and Don’t allow. It’s hard not to feel that this is at least in part a response to Uber-like-apps decisions to make apps unusable when a user doesn’t allow access to location all of the time.
At first, you might think that this would spell the end to apps using location, since what use would ever not select the big, bold, perfectly located “Don’t Allow”. But I actually love this change and think (as does Apple) it has two really positive outcomes that help permission to data not hurt it:
User focused design of permissions
We can think of this change as Apple’s way of forcing a user-centric design to an app’s permissions flow. Apple hasn’t really changed what an app can do, but they’ve put the onus on the developer to request permissions only when the user has been given enough context to understand and believe in an apps need for that data.
This is great and I think has an entirely positive impact on a user’s willingness to share data. Some of my favorite onboarding experiences lately (e.g. Yummly or Poncho) have really gotten this right.
User-directed value flow
The second interesting change is that by not making the user feel forced, these new permissions may actually make it easier for applications to request access to location data. To ask for this data now, your app just needs to be able to explain what features or values your users can get only by sharing location. Combined with the blue bar of shame, users can be a bit less paranoid about how apps plan to use their data.
This is in-line with how our team thinks about user data: users should only provide their data if they are getting a feature or service they value in return. We didn’t expect Apple to make such big changes so fast, but it’s awesome to see! Apple goes further in their WWDC17 talk linked above, explaining that apps should almost never request “Always” out of the gate, but instead should got step-wise based on features. First request, “While in Use” and then later, when the user arrives at a feature dependent on location all the time, step them up. In this flow, the user actually gets a different prompt.
Getting started in your app
If you are a Swift developer and interested in playing with each of the tested APIs above, we threw together some quick starter apps for you to jump into: Geofences, Visits, Significant Changes. If you are looking for better ways to use manage location in your app, get in touch!