Industry

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.

https://s3.amazonaws.com/io.radar.blog/posts/understanding-new-location-permissions-in-android-q-and-ios-13/13_q.png

Android Q

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_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:

https://s3.amazonaws.com/io.radar.blog/posts/understanding-new-location-permissions-in-android-q-and-ios-13/q_1.png

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:

https://s3.amazonaws.com/io.radar.blog/posts/understanding-new-location-permissions-in-android-q-and-ios-13/q_2.png

iOS 13

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 Always (background).

iOS 13 introduces a third option: Allow Once. This option allows users to grant When In Use for a single session:

https://s3.amazonaws.com/io.radar.blog/posts/understanding-new-location-permissions-in-android-q-and-ios-13/13_1.png

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 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:

https://s3.amazonaws.com/io.radar.blog/posts/understanding-new-location-permissions-in-android-q-and-ios-13/13_2.png

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.

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:

https://s3.amazonaws.com/io.radar.blog/posts/understanding-new-location-permissions-in-android-q-and-ios-13/13_3.png

The impact

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:

  • Transparent: The prompt explains what data will be collected from the end user and how it will be used, with a link to your privacy policy.
  • Valuable: The prompt explains why the user should grant location permissions, like enabling a valuable location-based feature.
  • 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. Want to stay in the loop about additional changes? Follow us on Twitter @radarlabs or subscribe to our newsletter below.