Core Location

Overlooked in the post-WWDC hubbub of SwiftUI, Reality Kit, and ML advances, were some small but significant changes to the CoreLocation framework. Continuing Apple's focus on privacy and increasing user responsibility for their data, the CoreLocation framework has undergone an overhaul that will change the way your app manages and accesses the user's location. The ramifications are wide-sweeping, so let's get right into it.

Provisional Access

Location access is now granted provisionally when requested by the system. For example, when your app requests "Always" Authorization and the user selects "When In Use", your app will actually receive "Always" temporarily, since this is what was asked for. At some point in the near future (a time determined by the system, based on when your app is typically used by the user) the user will be prompted again, this time asking the user to either confirm "When In Use" was what they wanted, or to switch to "Always". This second prompt is guaranteed to happen once and only once, and your app will receive the final authorization level upon user input.

Important to note is how these authorization levels will exist on all devices. For now, TvOS does not support "Always", WatchOS does not need to support "Always" (because of the usage patterns of the watch, expecting the user to have your app in the foreground is reasonable), MacOS does not have "Always" or "When In Use", but iPad Apps for Mac may use either "Always" or "When In Use".

API Access

API level access for CoreLocation has changed as well, making new functionality possible this fall. In iOS 12, certain features of the Core Location framework, like starting Location Monitoring in the Background, using Significant Location Change Monitoring, Region Monitoring, and Visit Monitoring were unavailable with "Always" authorization. This fall, with iOS 13, all Core Location APIs are available from the get-go, and the only change is when these events are sent to your app. If your app has "Always" authorization (either provisional or deferred), your app will receive events when it is in use, and when it is not in use. When your app has "WhenInUse" authorization granted, it will receive these updates only when the user is using your app.

It's important to note that your app will be considered "in use" while it is in the foreground, and also for a short "grace" period following the app being backgrounded. This period is generally when some system cleanup happens, and shouldn't be relied on to do anything complex. This small detail becomes a lot more important when any of the provisional access levels are granted to your app. For example, with "When In Use" access granted provisionally, the system will be very sensitive to detecting the end of the user's session.

Takeaways

There are several ramifications to these changes, for product owners, developers, and designers to all consider. Firstly, even more attention needs to be paid to Authorization requests. Because the request dialog only appears a handful of times, the messaging behind these requests needs to be extra clear and precise, even more so because the pattern users are used to is now changing.

Secondly, because provisional access can be demoted or denied later, apps should be aware that the possibility of changing authorization levels is more likely going forward, and your app should make use of any location data offered as soon as it is offered. A scenario can be imagined where a user grants "When In Use" provisionally, backgrounds the app for an extended period of time (maybe to look up an address from the internet), and returns a while later only to find location isn't available anymore. This is a scenario that was possible before, but likely will occur more often now that provisional access is a possibility.

Finally, it's important to note that all APIs are available with any level of access now. This means that previously, if your app did something like Region Monitoring, you should update your app this fall to make it clear to the user you no longer have to request an authorization level of "Always". This means more functionality will be available, and with the prompts set up the way they are, you are more likely to get some level of access to the data you need.

While the WWDC talk for the CoreLocation updates was short, there were a lot of significant changes that users will be expecting Apps to adopt this coming Fall. These changes seem to be a good balance between user concerns and business requirements, and should enable a better user experience and more functionality for apps going forward.

About the Author

Allen White is a Senior Consultant based in the Columbus, OH area. He has a passion for writing sound software and seeing projects across the finish line. In his spare time, Allen enjoys sailing, studying Bitcoin, and spending time with his daughter.