Understanding new location permissions in Android Q and iOS 13
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.
1. Background location permission
Prior to Android Q, there were two location permissions:
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.
2. Background location reminders
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.
1. "Allow once"
Prior to iOS 13, there were two location permissions:
When In Use (foreground) and
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.
2. Changes to background permission prompts
With the introduction of
Allow Once, the user must grant
When In Use before you can prompt for
If you request
Always before the user has granted
When In Use, the user will only have the opportunity to grant
When In Use or
Allow Once. If the user grants
When In Use, iOS will grant provisional
Always, then automatically prompt the user for non-provisional
While the documentation suggests that you can still manually and incrementally prompt for
When In Use, this does not work as of beta 1.
3. Improved background location transparency
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:
- Valuable: The prompt explains why the user should grant location permissions, like enabling a location-based feature or unlocking an offer.
- Timely: The prompt is shown when the user is engaged, like in an onboarding, when accessing a location-based feature, or after a transaction. Background permission prompts are shown after and incremental to foreground permission prompts.
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. If you need to support iOS 13 or Android Q, Radar has you covered.
Radar SDK v3, available soon, will accommodate these changes and introduce other new functionality as well.
Want to stay in the loop about SDK v3 and additional changes? Follow us on Twitter @radarlabs.