iOS 13

In iOS 13, Apple introduced the Allow Once option for location permission. The flow of permissions is now as follows:

When a user opens the application for the first time, they are prompted to enable location permissions. The user can choose between Allow Once, Allow While Using App, and Don't Allow.

1. If the user selects Don't Allow, the application does not get location access. This is a terminal state, and the user will receive no more prompts asking for permission.

2. If the user selects Allow Once, the application receives location access for that session. The user will receive the same prompt the next time the application is used.

3. If the user selects Allow While Using App, the application receives provisional permission to capture location data.

If the user grants Allow While Using App access, then the next time the SDK requests background location permission, the user receives a prompt asking if the application may continue to use location data in the background. The user can now choose between Keep Only While Using and Change to Always Allow.

1. If the user selects Keep Only While Using, the app may not capture location data in the background. This is a terminal state, and the user will receive no more prompts asking for Always Allow permission.

2. If the user selects Change to Always Allow, the application receives full permission to capture location data in the background. However, this is not a terminal state.

If the user grants Change to Always Allow, iOS will occasionally send the user a reminder prompt, giving the users the option to Change to Only While Using or to Always Allow.

The user must continue selecting the Always Allow option every time they receive the reminder for the application to retain background location permission. If at any point, the user selects Change to Only While Using, iOS revokes background location permission and enters a terminal state, which means that the user will receive no more prompts.

See our FAQ below for how this affects new and existing users.

Recommended Solutions

The problem with the new model is that the request for Always Allow location permission may or may not be presented to the end-user in a favorable amount of time. Without the Always Allow permission, Zendrive cannot record trips in the background, which is how most trips are recorded.

There are three approaches we recommend to tackle this problem:

1. The Descriptive CTA solution

2. The during sign-up solution

3. The scheduled notification solution

The Descriptive CTA Solution

iOS provides a blurb in each of their prompts for the application developer to explain why they need location permission. We believe that because users will receive repeated prompts, they may think that iOS is warning them about your application. To address this, we recommend copy that tells users that these prompts are normal reminders, and to clearly inform the users about why the application needs background location permission.

We recommend the following standard text:

• For customers primarily using our mileage features: "Without background location access, <appname> cannot record trips correctly. This may affect your mileage and expenses."

• For customers primarily using our driving events and score features: "Without background location access, <appname> cannot record trips correctly. This may affect your driving analysis and scores."

• For customers primarily using our safety features and collision detection:

  Without background location access, <appname> cannot record trips correctly. This may affect safety features and collision detection."

The During Sign-up Solution

In this approach, we recommend directing the user to grant Always Allow permission immediately after they grant the first location permission. Your application displays a request for the appropriate permission, and a button to take them to the App Settings screen. Your application should direct the user to Your App Settings > Location > Always.

Zendrive provides an interface for you to implement this strategy.

@interface LocationPermissionUtility : NSObject
+ (void)showPermissionScreenIfNeeded:(BOOL)requestPermission;
...
@end

The Scheduled Notification Solution

In this approach, we recommend scheduling a predefined notification that will be triggered if a certain amount of time has passed and if your app does not have the Always Allow permission.

If both conditions are met, the app sends the user a notification, which directs the user to the app settings page (Screen 3 above).

Zendrive provides the following interface to implement your scheduled notification. The values given have defaults, as indicated in the comments.

@interface LocationNotificationConfiguration : NSObject
 //Default: false
@property (nonatomic) BOOL showRecurringNotification;

 //Default: 7 days (in seconds)
@property (nonatomic) long long notificationTriggerDelay;

 //Default: "App is unable to record trips"
@property (nonatomic) NSString *notificationTitle;

 //Default: "Please grant Always access for location."
@property (nonatomic) NSString *notificationDescription;
@end

@interface LocationPermissionUtility : NSObject
...
+ (void)scheduleNotificationIfNeeded:(LocationNotificationConfiguration *)configuration;
+ (void)handleNotification:(UNNotification *)notification;
@end

F.A.Q.

How do iOS 13 privacy changes affect new users?

New users will go through the full process of receiving 3 prompts - request, upgrade, and reminder - from the system. The Zendrive SDK will not be able to record trips in the background until it either receives Always access from the upgrade prompt, or the user manually changes the settings.

How do iOS 13 privacy changes affect existing users?

Existing users who've already granted Always permission will now start receiving reminder prompts. We recommend guiding them using our descriptive CTA approach, sign-up approach, and scheduled notification approach to continue giving Always permission to the app.

Will the customer need to upgrade to SDK 6.0 for changes to be addressed?

Strictly speaking, no. However, we strongly recommend that you implement our scheduled notification approach to ask users for permissions, no matter which version of the SDK is used.

How can an application recover a user who may not have granted the Always Allow permission?

We have provided the scheduled notification approach and the suggested copy in this section, which should allow you to recover users and guide them towards giving you the Always Allow permission.