Core Location in iOS 8

Location Services have been supported in iOS since iOS 2.0. With each release of iOS
Apple has improved and added new features in the Core Location framework, like geocoding, background location, region monitoring and iBeacons.

iOS 8 also introduced several enhancements and changes in the Core Location framework. With iOS 8, the Core Location framework has been enhanced to improve user privacy while enable developers to build new types of apps that they couldn’t before. Specifically, iOS 8 brings three new changes to the Core Location framework:

• More granular permissions
• Visit monitoring and
• Indoor positioning.

In this post, we’re going to look at the first two.

PERMISSIONS

Changes in permissions are meant to provide the user with more precise control over their privacy. Before accessing the user’s location, an app needs to first request permission to access it with reasons why it needs to do so. For instance, a GPS app that provides turn-by-turn directions needs constant access to your location so it can tell you when to turn. A restaurant recommendation app might want to access your location (even when it’s not open), so it can send you a push notification when you’re near a restaurant your friends like. A Twitter app might want to access your location when it posts a tweet, etc.

Before iOS 8, you either had to give an app permission to use location services anytime or not at all. The iOS settings app would show which apps were accessing your location in the background, but you couldn’t do anything except block the apps from using location services entirely.

Prompt presented in before iOS 8

Location Settings pane, before iOS 8

New Authorizations

iOS 8 breaks down the location access authorization into two types:

• “When In Use” – i.e. you give the app permission to access your location only when the app is in use.
• “Always” – you allow the app to access your location at all times (even when the app is running in the background).

These new permission request types are presented to the user in the form of the following prompts.

What the User Sees:

App explicitly requests WhenInUse authorization

App explicitly requests Always authorization

The above dialogs are presented only once and their text is customizable by the app requesting authorization.

For the “Always” authorization type, iOS 8 prompts the user for permission access again a few days later, to ensure that they’re truly comfortable with sharing their location with the app at all times (as depicted in the screenshot below).

To accommodate these new location permission types, the iOS Settings pane has also been modified (as shown below).

Furthermore, the app’s settings provide a link to a Privacy option that includes the permission authorization for location access (as shown below).

These new app settings can be accessed directly using the URL constant UIApplicationOpenSettingsURLString.

[[UIApplication sharedApplication] openURL: [NSURL urlWithString:UIApplicationOpenSettingsURLString]];

If an app needs both types of location access authorizations from the user, the location access permissions dialog will be presented only once when either of the two authorization types are requested. So then, how do you request authorization for the other type of location access? To do that, just open the new app settings pane for location access.

Developer Adoption

The above addition to location access permissions is a major boon for user privacy, but it does involve a bit more effort on the developer’s part. Prior iOS 8, requesting location permission was done implicitly by the OS itself, prompting the user to authorize access to location services (the first time they accessed the app), via the following code.


#import
#import
CLLocationManger *manager = [[CLLocationManger alloc] init];
If ([CLLocationManager locationServicesEnabled]) {
[manager startUpdatingLocation];
}


Since the location functionality authorization for apps is now split into two categories, your app can use location services either for:

• Continuous Updates – i.e. by using location services like location, background location, ranging.
• Location Monitoring – by using location services like region monitoring and significant location changes.

The following matrix provides a better idea about which authorizations are supported by which category.

To adopt the new authorization types in your app, you need to follow 3 simple steps:

Decide which authorization you need in your app by asking yourself:

• What location functionality is being used?
• Is it mandatory for your app or just a nice to have?

Explain it to your users by:

• Adding the corresponding keys to your info.plist explaining how your app uses location (as shown below)

Deprecated list key:

Replaced with two new keys:

Example:

• Make the right API call when needed

Also, be sure to check for the newly added authorization status’ enum values.

CL Authorization Status Authorized is deprecated

You might be thinking, what if my app requires both location authorization types? Don’t worry, because it’s not possible for any iOS app to require both authorization types at the same time.

Since you need to request an authorization only when the user performs some action that can only be completed by accessing location services, otherwise the user can deny the request.

Thus let’s assume that the app would first request the WhenInUse location permission (via the following code).

Now, when the user wants to use a feature in your app that requires the “Always” location access authorization, you can prompt the user for it and take the user to the app’s new settings pane (shown below).

Backwards Compatibility

Supposing your app supports both iOS 7 and iOS 8 and you want to request location access accordingly. You can do this by following the steps below.

• Continue to provide the deprecated NSLocationUsageDescription
• Guard the request authorization API calls with respondsToSelector:
  If ([locationManager respondsToSelector:@selector(requestAlwaysAuthorization)]) {
  [locationManager requestAlwaysAuthorization];
  }
  else {
  locationManager startUpdatingLocation];
  }
• Continue to use the deprecated kCLAuthorizationStatusAuthorized value.

If the user updates iOS version to iOS but not your app, then your app will still continue to work and will use the “Always” authorization for location access.

VISIT MONITORING

Although the Core Location framework provides many great features like significant location changes, deferred location updates, Geofencing, background location updates and automatic pause, they are not that useful if you’re building a journaling app. Since a journaling app at the very least provides features like:

• A list of places that the user has visited during the day.
• Ensuring that this list of locations is relevant (if you’re going to give the user every location where he/she has stopped during the day, they may not find that useful).
• Suitable for 24/7 use. The app should be capable of running for the entire day without consuming a lot of battery power.

Coding such an app however, means that it will consume a lot of battery life, due to location monitoring and custom processing (for making sense of the location events it records). Thankfully though, Apple has introduced a new core location service called Visit Monitoring (or Visit Detection) in iOS 8 that resolves this problem.

Visit Detection

The way this services works is that whenever the user stops at some point, for e.g. a coffee shop, the system doesn’t immediately consider this to be a visit to that location because the user might just be passing by. The system thus waits for more data, which is received if the user spends some time at that particular location. Only then does the system register that location as ‘visited’ (arrival or departure) and delivers the events to the app. When a visit is detected, the system does its best to estimate the user’s arrival/departure time and records that as well.

Furthermore, the visit monitoring service is different from other services in the Core Location framework in the sense that:

• It monitors for destinations only i.e. instead of giving information about how the user went from A to B, it gives information about locations A and B.
• It launches the app when it detects a visit to a particular location i.e. the user arrived or departed from that location.
• It requires the ‘Always’ location tracking permission/authorization.
• It is power efficient – Apple claims that this new feature is incredibly power efficient and its engineers have employed all sorts of neat tricks to ensure that it is.
• It is an opportunistic use of location tracking i.e. if your app uses the visit monitoring service and the user switches to the Maps app or any other app that uses location services, the system takes into account all of those events in the visit detection algorithm, so that your app benefits from other apps using location services.
• It utilizes information from the whole system. For example, if the user arrives home and plugs in their phone for charging, the system assumes that the user plans to spend a good deal of time there, based on the fact that they’ve plugged in their phone for charging at this location. So the system uses the charging process as a hint that user has just arrived somewhere important and trigger the events for location tracking.

Now that you’ve understood how the visit monitoring feature works, lets take a look at its API. There are basically two new methods available in the CLLocationManager class for starting and stopping the visit monitoring service (shown below).

There’s a new delegate method for delivering information about location visits (depicted below).

And also a new class called CLVisit that represents a visit (shown below).

Some Points to Note

• The values of horizontal accuracy and coordinates may differ between an arrival event and a departure event, since these are the estimates based on the data the system sees. However horizontal accuracy you obtain from this feature is no worse than the Wi-Fi based horizontal accuracy typically used by apps.
• Since this is a background location monitoring service, the app is launched even when the user has closed it or even if it has crashed, and even when the device is rebooted.
• Multiple visits may sometimes be recorded. These multiple visits are not delivered as an array but rather, the delegate is called multiple times. So you should be prepared to handle this scenario in your app.

If you perused the CLVisit class, you might have noticed that there is no way of knowing whether the event delivered is an arrival or a departure, as it has both the arrival and departure dates. So how do you which is correct? It’s quite simple. Just look at the following matrix to see if you can spot the answer.








Still not sure? It’s easy. Just define a method to differentiate between the arrival and departure events, as shown below.








And that’s it! To learn more about the new features introduced in the Core Location framework in iOS 8, check out the WWDC 2014 Core Location Session video.



Explore our blog




ABOUT FOLIO3

As a leading mobile app development company (iPhone, Android, Windows Phone, HTML5 app development), Folio3 specializes in native app development services and cross platform mobile app development services for the iPhone and iPad. We also offer extensive mobile app testing and QA services. If you have a mobile app idea that you’d like to discuss please or would like to know more about our iPhone app development services, please Contact Us. Learn more about our iPhone, Android and Windows Phone app development services.

Blog Post