Impact of iOS13 & iOS14 location permissions on background location access

Consumers expect apps to access location while the app is in use in the foreground, be it turn-by-turn navigation, blue dot on the map, or location-based content. Users have different expectations from work apps. Field service management, salesforce automation, gig work, fleet automation, and delivery management apps stay in the background most of the time, while the user is focused on fulfilling work on the field. Business uses high-frequency location for routing orders, tracking progress, sharing live location with customers, logging actual miles and more.

It is business critical to make ambient location tracking robust within the dynamic conditions of the mobile phone and the external environment it operates in. In this post, we discuss the impact of user-controlled location permissions on background location access.

What does background mean?

When we launch an app we know that it's running, because we see it on the screen. To understand what happens with the app when it's not showing on the screen we first need to understand the concept of running.

In iOS, apps respond to events, like a user pressing a button, scrolling or launching the app. When an event happens, iOS runs the app's code by handling the event that happened. Apps usually take very little time to process each event and after processing is done, the app's code is no longer running until the next event comes in.

When the app is showing on the screen, it handles all incoming events. iOS calls this state foreground. When the user switches to another app or locks the phone, the app transitions to background state. By default iOS stops forwarding any events to the app and gives it a couple of seconds to finish processing the events originated in foreground. After the app finishes processing, it further transitions from background to suspended state. iOS doesn't give the app any new events, and the app's code is not running.

You may have noticed that there are only a couple of seconds that the app can usually spend in the background, so how does background location tracking work? This is where permissions come into play.

The difference between permissions

iOS allows the app to ask user for permissions using two different API calls:

Request When In Use permissions by using requestWhenInUseAuthorization() call
Request Always permissions by using requestAlwaysAuthorization() call

Let's understand each permission and its impact on location access.

When In Use

iOS 13 considers the app in use from the time when it was brought to foreground by the user until it is suspended.

If your app asked for When In Use permissions and user granted them, your app gains an ability to start handling location events in foreground (by calling startUpdatingLocation()) and then continue in background until your app calls stopUpdatingLocation() or user revokes permissions. Until that happens the app can stay in background state indefinitely.

Requesting When In Use permissions has another effect. When your app is in background, a blue indicator (pill or bar) will be shown, reminding the user that the app continues to track location. Users can tap this indicator to return to the app.

Always

Always permissions give your app an ability to wake up from suspended state and start tracking while your app is not showing on the screen. OS itself can wake up your app in response to a significant location update or your app can start tracking in response to a silent push notification.

The app can also hide the blue tracking indicator.

What permissions should your app request?

Request When in Use permissions if:

Your app starts accessing location only in the foreground or requires user action to start tracking, such as when user logs in, starts a shift, or accepts an order
Your business can tolerate tracking outages after interruptions, such as phone reboots or users swiping up the app from the multitasking UI

Request Always permissions if:

Your app needs to start tracking without user action in the app, usually from the backend, such as automatic order assignment or time-based start of shift
Tracking location is vital for business logic, and gaps in data will result in bad user experience for customers or lack of visibility for operation managers

How to handle a user's response

Your app can request When In Use or Always permissions, but the user always has a choice. Your app needs to handle the user's choice gracefully.

When In Use

If your app requested When In Use permissions, users will see the following dialog:

Permissions dialog user sees when app requests While In Use permissions

User choosing Allow Once option grants your app the same permissions as choosing Allow While in Use, except they reset to an unrequested state when the app is suspended. It is like marking an email unread in your Inbox after reading it–this has the effect of making the next app launch feel like first use with regard to location access permissions.

After the user grants When In Use permissions, your app keeps a one-time ability to ask the user to upgrade them to Always.

Always

If your app requested Always permissions, users will see the same dialog as for When In Use, except the consequences of the user choosing the options are different.

iOS 13 shows the user the same permissions dialog when app requests Always permissions

Even though your app requested Always permissions, Allow Once grants the same temporary When In Use permissions as if your app requested When In Use in the first place.

The user choosing Allow While in Use though, starts a multi-step process, called Provisional Always Authorization.

Provisional Always Authorization

During Provisional Always Authorization, iOS13 does not deliver location events in the background.

That's right, during this period it's even worse than requesting When In Use permissions.

iOS13 does this to check if the app will use a location API that requires Always permissions. In our case, continuing to track in background fits the requirements, and usually next time user checks their home screen a second dialog appears:

iOS 13 only shows this permission dialog on the home screen

This prompt appears automatically when iOS algorithms conclude that the user is not busy and is currently on the home screen. The app has no control over the timing, but in our tests, the prompt appears shortly after switching to the home screen during active location tracking.

Once the user chooses either Change to Always Allow or Keep Only While Using, your app starts receiving location events. This event marks the end of Provisional Always Authorization state. Here is how the whole flow looks like:

Your business logic and operation managers should be prepared for the initial gap in data right after the user chooses Allow While in Use and the app enters background.

If you want to make this gap as short as possible, you can:

On the screen where you request for Always permissions, explain that your app requires the user to choose Change to Always Allow on the second prompt and/or navigate the user to the Settings.app to manually end Provisional Always Authorization by switching permissions to Always Allow:

User choosing Always on this screen automatically end Provisional Always Authorization state

Programmatically detect that you are in Provisional Always Authorization, and display an overlay message advising your users to set permissions to Always Allow in the Settings.app.

iOS13 does not provide any API to check if your app is in Provisional Always Authorization, so the only way to be sure that your app is currently in it is to check if your app continues to receive location updates after it transitions to background. No updates mean your app is still in Provisional Always Authorization and when the first location is received in background you can be sure that it's ended.
Starting from iOS 13.4, if your app first asks for When In Use permissions, and after receiving them asks for Always, iOS doesn't transition to Provisional Always Authorization state but instead shows the second dialog immediately, in the context of your app. This way, your app can avoid Provisional Always Authorization entirely by first asking for When In Use, continuing tracking in the background, and later, when the user returns to the app, upgrading to Always, all without introducing gaps in location data.

Be advised that the user can change authorization in Settings manually to Ask Next Time, which resets your app's permissions into an unrequested state immediately. This will suspend your app if it was still tracking in background. After your app is launched again, the Provisional Always Authorization process can start once more.

Accuracy authorization in iOS14

iOS14 introduces a new dimension to location permissions. On the one hand, When In Use and Always define the circumstances in which the app can use location; on the other, Accuracy Authorization defines the frequency and precision of location data.

In iOS 14, every time your app asks for Always or When In Use permissions, user will have the option to also choose the accuracy. The two options will be:

Full Accuracy, which works the same way as previous iOS versions do,
Reduced Accuracy, which only provides a 1-20 kilometer circular area that covers the current user's location. iOS14 only guarantees that the user is somewhere inside this area. The frequency of updates is also reduced to four updates per hour.

User will also be able to switch between the two in settings at any point in time. This might be okay for consumer apps that don't require precise location access, but is a non-starter for field service and logistics apps.

Luckily, iOS14 has APIs to query the current status of Accuracy Authorization and to subscribe to any changes. Once your app detects Reduced Accuracy state it can:

Navigate the user to Settings.app to flip the Full Accuracy switch on for Precise Location.
Use the new API to request temporary Full Accuracy authorization. This is analogous to Allow Once option, where Full Accuracy will be available while the app is in use.

Choosing between the two can depend on how location is used in a business context, but in most cases blocking the app until the user enables Precise Location is the right way to go.

Publishing the app on the App Store

Since this blog is about background location access, there is one last thing to be cautious about–passing the App Store review. Here are some tips that will help you avoid pitfalls:

Your app should have permission strings that clearly explain to your worker why the app needs their location. Those strings will be displayed in permission dialogs and in Settings.app.
Don't ask for permissions right when the app starts. Instead ask for permissions after the user action that starts location tracking session. It is best to have a separate screen in the app, explaining the use of location tracking with a button that triggers permission dialog.
App Store review requires your app to have visible features that depend on background location access. For example, your app can have a map, showing the worker his route to a customer, or a visual element explicitly explaining that location tracking is currently active and is used to automatically complete a task the worker is performing.
When submitting your app for review, include a video showcasing all your app features that require location permissions to test. App Store review team usually doesn't want to grant those permissions and the video significantly speed ups the review process. A link to an unlisted YouTube video works great in most cases.

Was this useful?

Please let us know if this post helped and contribute your thoughts to make it better. Collaborating with developers working on similar problems is important to us. We are always happy to hear your thoughts and feedback.