Understanding New Location Permission Changes in iOS 13

These changes give end-users more transparency and control

Tejeshwar Singh Gill
Better Programming

--

iOS 13 introduces a number of changes in how developers are able to use user locations. It introduced four major changes: 1. an “allow once” option, 2. changes to background permission prompts, 3. improved background location transparency, and 4. a changed “always allow” option.

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. The “Allow Once” option is considered a temporary authorization, with the app prompting again the next time it’s opened. 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. When you request location permission trough CLLocationManager, the user will see this popup with three choices:

  1. Share the location just once with the app and ask again
  2. Share the location with the app when the app is in use
  3. Don’t share location with the app at all

If the user taps option 1: “Allow once”, your app will be notified that the CLAuthorizationStatus changed to authorizedWhenInUse. Just as you’re used to in older iOS version when you get a permanent permission. It is now allowed for your app to start requesting locations — no code changes necessary.

Users can jump out and back into their app, and you will still have location permission. It’s only after a (longer) period of inactivity that iOS will revoke the permission and turn the CLAuthorizationStatus back to notDetermined. Your CLLocationManagerDelegate will get notified of the change in location permission when the app is back in the foreground so the UI can be updated accordingly.

This makes the new ‘allow once’ feature a nice privacy improvement for users. It also lowers the bar for users to give the location features in your app a try and decide later whether to grant it a more permanent permission.

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

Getting consent to scan for a location in the background has become a bit harder, but in exchange, your users will enjoy more transparency regarding the locations you’ve received in iOS 13. The first notable change is that even when you call requestAlwaysAuthorization, the user will only get the ‘just now’ and ‘when in use’ options in the permission dialog. If the user grants you ‘when in use’ permission and you try to scan for location in the background, only then will the user be presented with a dialog to grant the background permission.

This is different to what we’re used to in older iOS versions where the user was allowed to give the “always”-permission directly at the request. On a code level, the only difference will be in the moment you receive the permission. If you make sure not to base the value of allowsBackgroundLocationUpdateson whether or not you have background permission, the second permission dialog will never change.

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:

After your app has been tracking the user’s location in the background for a while, iOS will make sure it still has the user’s consent. In the new iOS, this consent renewal dialog will include a small report with the locations your app has been tracking, as shown in the figure above. This makes what’s happening in the background more transparent to the user

4. “Always Allow”

The user is not required to manually intervene in order to explicitly grant the “Always Allow” privilege. By design, they are asked again at a later point. Because of this, it would be a violation of the guidelines to ask the user to open the settings app and forcibly grant the “Always Allow” privilege.

  • As a developer, in your code, you should request “Always Allow” as you normally would.
  • The user will see the new prompt which does not have the “Always Allow” option.
  • If they grant “Allow While In Use” privileges, your app will actually be granted “provisional authorization” for the “Always Allow” privilege.
  • The developer should now simply proceed to do the things for which they need that permission for: e.g., set up some geofences, and start monitoring for notifications, whatever.
  • If the developer has coded their app according to the guidelines, at some point when a location-based event is triggered, the user will be prompted again. This time they’ll have the option to grant the “Allow Always” privilege, at which point the provisional authorization will be made permanent.

Conclusion

These changes are great for end users, giving them more transparency and control.

However, if you want to access location data, you must deliver value to the end-user and you must be transparent.

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.

Do read and share !!

Thanks to the researchers at Radar for their detailed insight !

--

--

(aka IrØn∏∏anill) . Speaker NASSCOM, Architect, Engineering Manager M: +91–9873581799 Linkedin: https://www.linkedin.com/in/tejeshwargill/