iOS 13 Limitations and Permission Management

Apple has recently made major changes in permission flows with iOS 13. There is now a new option of "Allow Once" along with multiple level of permission prompts for location access.

In this article, we explain the new permission flows with iOS 13 along with recommended flows to ensure user experience and trip detection effectiveness of app is maintained. We will also discuss limitations and effects of various permission states on functionalities Kruzr SDK can offer to your app.

A correct implementation of location flows is crucial to ensure your mobility app is able to correctly identify trips and driving states.

Understanding Permission States in iOS 13

iOS 13 includes three categories of permission prompts any user will receive for Location permissions. The prompts are meant for users to have 3 level check on the exact permissions and level of access your app will have for location and motion data. The three levels of prompts are as follows -

1. Initial location access prompt: It is the first prompt to your users for sharing location data with your app. There are three options you can provide to users at this stage: Allow Once, Allow While Using App, Don't Allow. As we will discuss in this article later, we recommend that you mandatorily collect this permission from users during On-Boarding/User Registration ensuring your user has at least provided "Allow Once" permission before you even load your first driver's home screen - this will ensure a smooth experience for your users when they have just started to use the app.

2. Upgrade location access prompt: Apple has included an upgrade location access option for apps wherein if the app wants to "upgrade" location access from "Allow Once"/"Allow While Using App" to "Always Allow". The prompt is shown when the SDK requests background location permission. If the user continues to select "Allow While Using App" at this stage, trip detections will be affected as Kruzr SDK will not be able to access location data necessary for automatic trip detections. Note that in this case, no further prompts will be shown to the user regarding location access and Kruzr SDK will be limited to detecting trips ONLY when app is in foreground. We will discuss later in this article about the difference between "Allow While Using App" v/s "Always Allow" and our recommendations on best practices to follow to ensure your users' trips are automatically logged by assisting them to provide "Always Allow" location access.

3. Reminder prompt: If within Step 2, user chooses "Change to Always Allow", further reminders are provided to the user about the app using background location. At this step, the user can again select between "Change to Only While Using App" or "Always Allow". As mentioned in Step 2, it is crucial that users continue to select "Always Allow" when these prompts are shown. Alternatively, a better approach is by helping users select "Always Allow" directly from iOS Settings which we will discuss later.

A schematic diagram of permission flows and their implications are as follows -

Permission states, prompts available to users on iOS 13

Implications of Permission States on Kruzr SDK

As you may have already interpreted from the above description, it is important that we are able to collect "Always Allow" permission from users to correctly identify and log trips via our SDK. The following table summarizes the permission states and whether our SDKs functionalities will be available -

Permission State	App killed	App in background	App in foreground
Don't Allow	No	No	No
Allow Once	No	No	Only for current session
Allow While Using App	No (Yes for first 3 days from app installation)	No (Yes for first 3 days from app installation)	Yes
Always Allow	Yes	Yes	Yes

However, these changes in permission states are not the end of the road for iOS mobility applications. In the next subsection, we present two approaches which will ensure that users are well educated on importance and impact of these permission states and help your app collect the necessary permissions for Kruzr SDK to work normally.

Approaches to Ensure User Provider Required Permissions

In this section, we will look at 2 approaches with examples that your team can implement to ensure Kruzr SDK works in all situations and your users are at ease and comfortable while providing those permissions.

We recommend two levels of permission collections from users -

1. During On-boarding/User Registration - to ensure that we have location permission for first 2-3 days of usage post installation and user registration on your app

2. After On-boarding - providing users a quick and easy way to permanently provide "Always Allow" permission to your app via relevant methods of reminders and reinforcements

We will look at each of them in detail with descriptive illustrations that will help you include these flows into your app.

Getting Minimum Permission States during On-boarding/User Registration

Onboarding/User Registration is one the best ways to communicate to your users about the importance of location and motion permissions when they are using any mobility app. It is also one of the few occasions where we have complete attention of users on the app screen.

Therefore, we recommend using this opportunity by creating a permission based "pre-screening" before your user can start interacting with the app. It can be implemented by designing mandatory permission cards before users can load their driving app screen. As a new app, you may be tempted to skip this step, but we strongly recommend including a permission based filter at the outset since your users will not be able to even experience the capabilities or score their trips if they have not provided these "minimum" permission states.

An example of such a flow is as follows -

Utilizing On-boarding/Registration process to clarify expectations and app permission requirements

Getting "Always Allow" Permission via in-App Reminder Cards & Notifications

Apple does not allow apps to push a direct "Always Allow" permission prompt at their discretion. However, one of the best ways to solve for that is via Reminder Cards and/or Notifications. We recommend using a combination of both approaches. Cards are also particularly effective since we can control the messaging of importance of "Always Allow" state when a user has probably opened the app to check their scores/trips.

We can also use Cards to redirect users to Apple Settings page wherein they can directly see the actionable permissions for your app.

An example flow of such approach is as follows -

Example flow for using reminder cards to redirect and remind users to provide Always Allow permissions

If you have any questions on this topic or need further support in ensuring your app is able to track and score all trips from your users, please feel free to reach out to [email protected] with your queries!