Since this post was published, we introduced a new location data privacy checklist with the latest and greatest best practices and Radar capabilities. Check it out!
Android Q and iOS 13, now in beta, introduce changes to location permissions. These changes are great for end users, giving them more transparency and control, but they raise the bar for developers requesting access to location.
In this post, we explain the changes, as well as best practices for building with location on iOS 13, Android Q, and beyond.
Android Q introduces two changes: (1) a separate background location permission and (2) background location reminders.
These changes effectively bring Android Q to parity with iOS 12.
You can learn more about these changes in this Google I/O video.
Prior to Android Q, there were two location permissions: ACCESS_FINE_LOCATION
and ACCESS_COARSE_LOCATION
. Both of these permissions allowed you to access location in the foreground and in the background.
Android Q introduces a third location permission: ACCESS_BACKGROUND_LOCATION
. On Android Q, the user must grant background permissions separately from foreground permissions.
Like on iOS 12, if you prompt for background permissions, the user will have the option to grant only foreground permissions instead:
If a user who previously granted location permissions upgrades to Android Q, they will be grandfathered into background location permissions after upgrading, depending on your app settings and build target.
You can learn more about prompting for ACCESS_BACKGROUND_LOCATION
in this documentation.
Android Q also introduces background location reminders. Like on iOS 12, if the user grants background permissions, Android will show a reminder after a few days, giving the user an opportunity to change settings:
iOS 13 goes further, introducing three more changes: (1) an "allow once" option, (2) changes to background permission prompts, and (3) improved background location transparency.
You can learn more about these changes in this WWDC video.
Prior to iOS 13, there were two location permissions: When In Use
(foreground) and Always
(background).
iOS 13 introduces a third option: Allow Once
. This option allows users to grant When In Use
for a single session:
After the session ends, you must request When In Use
again.
If a user who previously granted When In Use
or Always
upgrades to iOS 13, they will be grandfathered into that authorization status after upgrading.
With the introduction of Allow Once
, the user must grant When In Use
before you can prompt for Always
.
If you prompt for Always
permissions first, the user will see a When In Use
permission prompt instead. If the user grants When In Use
, iOS will show a second prompt to upgrade to Always
permissions later, either outside the app or on a subsequent app open, at a time determined by the OS:
While the documentation suggests that you can still manually and incrementally prompt for Always
after When In Use
, this no longer works as of the GM seed.
If the user grants Always
authorization, iOS will show a reminder after a few days, giving the user an opportunity to change settings. iOS 13 adds a map to this reminder to improve transparency:
These changes are great for end users, giving them more transparency and control.
However, Apple and Google have clearly raised the bar for developers requesting location permissions. If you want to access location data, you must deliver value to the end user, you must be transparent, and you must get clear opt-in.
The best location permissions prompts are:
These best practices are an opportunity to build trust with your users. Embrace them!
Our team works hard to stay on top of changes like these. Want to stay in the loop about additional changes? Follow us on Twitter @radarlabs or subscribe to our newsletter below.
See what Radar’s location and geofencingsolutions can do for your business.