Making sense of new background location restrictions in iOS 11 and Android O
iOS 11 and Android O, still in developer preview, introduce new background location restrictions.
As the CEO of a location data and developer tools startup, you might expect me to tell you that these changes are bad.
Instead, I'm here to tell you that these changes are unequivocally good for end users, and while they're bad for many apps and companies in the space, they're also good for "good actor" apps and companies in the space. Allow me to explain.
iOS 11 changes system indicators and permission prompts related to background location.
On iOS 11, the system displays a blue double-height status bar (the "blue bar") when an app uses the standard location service in the background. Previously, the system displayed only a solid arrow in the status bar.
Update: In an unusual reversal, Apple added a
showsBackgroundLocationIndicator property to
CLLocationManager in iOS 11 beta 5 that determines whether the blue bar is displayed. This property is
NO by default.
The standard location service is most commonly used in the background by navigation or fitness apps, but is also used in the background by apps like Moves and Foursquare. This change will likely force apps like Moves and Foursquare to stop using the standard location service in the background, lest users revoke permissions or uninstall these apps entirely.
However, the system will NOT display the blue bar for low-power location services like the region monitoring service (geofences and beacons), the visits service, and the significant location change service. Instead, the system will display a hollow arrow in the status bar when these services request a location, and temporarily display a solid arrow in the status bar when these services receive a location. Apple is encouraging developers to use these services, not to "beat the system" with their own solutions using the standard location service.
In addition to changing system indicators related to background location, iOS 11 also changes permission prompts.
iOS offers two types of location permissions, "always" (background) permissions and "when in use" (foreground) permissions. On iOS 11, apps that request "always" location permissions must also give users the option to select "when in use" location permissions. Previously, apps like Uber could request only "always" permissions, with no option for "when in use" permissions. Apple is encouraging developers to make a compelling case for background location access, lest users only grant foreground access.
You can learn more about these changes in this WWDC video.
Whereas iOS 11 changes system indicators and permission prompts, Android O adds new background execution limits that throttle the delivery of background location updates.
On Android O, apps using the fused location provider (the Android equivalent of the iOS standard location service) only receive background location updates a few times per hour. In addition, apps can only perform background wi-fi and Bluetooth scans a few times per hour. Previously, there were no restrictions other than Doze Mode and App Standby.
Like on iOS 11, low-power background services like geofencing are mostly NOT affected. Apps can still receive geofencing events every few minutes. Again, Google is encouraging developers to use these services, not to "beat the system" with their own solutions.
You can learn more about these changes in this Google I/O video.
These changes are unequivocally good for end users, and while they're bad for many apps and companies in the space, they're also good for "good actor" apps and companies in the space.
With these changes, end users will get more transparency, more flexibility, and better battery life.
What will developers get? They'll still get to build great product experiences powered by background location, provided that they follow the rules.
However, only "good actor" apps that deliver real value to the end user apps will get background location permissions. "Bad actor" apps that do not deliver value to the end user, or that attempt to "beat the system," will not.
When only "good actor" apps get background location permissions, end user trust will increase. And as trust increases, more end users will be willing to grant background location permissions, ushering in a new wave of product experiences powered by background location.
At Radar, part of our mission has always been to help companies build better products and services with location. In the location data space, delivering value to the end user is the winning strategy.
Need to support iOS 11 or Android O? Radar has you covered.
1.2 of the Radar SDK improves battery efficiency, avoids the blue bar on iOS 11, and avoids background execution limits on Android O. Upgrading requires no code changes and should only take a few minutes.