Starting location updates in background

It would be great (and we'd be grateful!) if someone from Location Engineering could confirm once and for all that standard location updates can't be started from the background (even if you have Always authorization).

To the best of my knowledge, you can only start location updates from the foreground. Maddingly, this isn't clearly documented anywhere that I can find. I think the best confirmation is WWDC 2014 Session 706 (What's New in Core Location) starting at 8:10 ("started in foreground"). However, the speaker is has just been talking about "WhenInUse" authorization, so it isn't completely clear if this also applies to "Always" authorization. It's a pity the API docs for [CLLocationManager startUpdatingLocation] don't address this directly.

My use case and experience were similar to yours. In my case, the app had started location updates in the foreground, but would set up a geofence and stop location updates to conserve power if the user stayed in an area for a few minutes . When exiting the region, starting location updates again would result in ~10 seconds of run time before being suspended. Perhaps there was something I missed in my implementation, but as far as I can tell, this scenario is not supported. It's a shame because it's an opportunity to save a lot of power, but I suppose it's also open to abuse.

By the way, you'll see folks playing games with background tasks and timers, but that's sketchy and unlikely to create the user experience you want. Good luck!

EDIT: I'd forgotten this from the iOS 8 API docs for [CLLocationManager requestAlwaysAuthorization], which is what lead me to try starting location updates from the background in the first place: "When the user grants “Always” authorization to your app, your app can start any of the available location services while your app is running in the foreground or background." However, my experience was the same as yours – it doesn't work that way.

Gualtier Maldè,

Thanks very much for responding – especially for the detailed and clear explanation; it's a huge help. Not sure if earth2stu is still out there, but I appreciate it. It validates the solution I settled on for my use case (adjusting deferred update parameters combined with geofencing), and I'll sleep a little better at night.

This is the kind of info that I wish could be included in the CLLocationManager API docs or in a technical note. I understand you want to abstract things and keep the details fuzzy to make it more difficult for "bad" developers from gaming the system, but knowing the determistic behavior saves hours of frustration for the rest of us. So, again, thanks for taking the time.

Finally, in case someone in management ever reads this: Having engineers field questions on these forums is invaluable. It not only helps developers directly, but it fosters a lot of goodwill towards Apple. Historically, it's been very hit or miss getting answers on the dev forums, and I've mailed Tim Cook about that before. Most of my questions over the years have gone unanswered, and it's why the dev forums have typically been the last place I looked. Maybe that's changing? I told Tim I thought there should be dedicated folks that monitor the forums and provide help – especially for the things that only Apple can answer (undocumented behavior, bugs, etc.). I understand that's a very difficult thing to do, but it's something that Apple should tackle. Imagine the applause at WWDC if Tim announced a team had been formed for that purpose. And, if there already is such a team (and for the engineers who help in addition to their regular workload), thanks! Consider this a vote for more folks and resources – and bonuses!

Thanks a lot for elaborating on this!

However, I have one additional question. What is the case with being launched in the background from an Apple Watch message (see "Introducing Watch Connectivity" ~32:00)? E.g. the Apple Watch Runtastic app can launch it's counterpart on iOS to start location updates (even if the iOS app is not running).

As far as I understand this is the only exception where the locationManager will not be killed after 10secs/3mins, right?

"What's new in Core Location" talks about this (~33:45) as well, but only mentions iOS apps to be considered as "In Use" when being launched from a Watch Message. Runtastic however is clearly using "Always" location mode.

Can you elaborate a little on how being launched in the background is being handled in the context of Apple Watch interaction?

Thx!

I have an application with the same use case that was deployed to the store several years ago and now I'm trying to upgrade to 9.2. I'm trying to tamper my frustration, but I don't understand why Apple would do this?? The approach of using region monitoring to detect an exit and then start detailed tracking seems to me to be a good efficient use of system resources. To prevent this forces the application to keep location services on all the time. Also, there are several posts that poin to the WWDC presentation, but that presentation does not provide an insight to solving this issue. I've implemented the request for always authorization and set background to YES. However, still cannot start updates in the background.

Thanks for responding. Could you please explain how "Find My Friends" works? Does it use location manager or any other features with system privilages?

I too would have the very same use case for my app. I would like to start location updates from a region update.

It´s a shame this is not possible :-(

Best

Stephan

An excellent and very informative reply, even after all this time!

thank you for taking the time.