Behaviour for significant change location API when terminated/suspended? Behaviour for significant change location API when terminated/suspended? ios ios

Behaviour for significant change location API when terminated/suspended?


Since I asked this question, I have done a fair bit of testing (mostly on the train between home and work) and have confirmed that the behaviour for suspended apps is as I suspected at the end of the question.

That is, your suspended app is woken up, you don't receive any callbacks on your app delegate, instead you receive your location updates through your existing CLLocationManagerDelegate. You can detect that you are running in the background by checking the applicationState, and do limited work for the case where you are woken from a suspended state to do location processing.

[UIApplication sharedApplication].applicationState == UIApplicationStateBackground

I came to this conclusion with a location test harness that you are welcome to download and try out. It is a pretty simple app that allows you to turn on significant change and GPS change APIs through the UI and log all the responses that you get back.

N.B. Point six in the previous answer is not correct. Freeze dried suspended apps do receive CLLocationManagerDelegate callbacks when they are woken up from a suspended state.


My understanding is as follows (I'm in the process of writing an application that relies on this API, but haven't completed this component enough to start testing):

  1. Your application is run for the first time, you register to startMonitoringSignificantLocationChanges, and provide a callback function. While your application is running, it will call that callback whenever it receives a significant change.

  2. If your application is put to the background, UIApplication will receive applicationWillResignActive, followed by applicationDidEnterBackground.

  3. If your application is killed while it is suspended, you will not be notified; however, if your application is killed while it is running (foreground or background to my knowledge), you will get a moment with applicationWillTerminate. You cannot request extra background time from this function.

  4. Despite being killed in the background, the OS will relaunch your application. If your application is simply launched by the OS for a change, you will get a call to application didFinishLaunchingWithOptions:

    if ([launchOptions objectForKey:UIApplicationLaunchOptionsLocationKey])

will help you determine if you've come back from a background location change.5. If, instead, you were currently running in the background, and your app is manually relaunched by the user, you will receive an applicationWillEnterForeground followed by applicationDidBecomeActive.6. Regardless of how it happened, when your application is relaunched (unless it was still running in the background as a result of a background task and said task had started monitoring changes), you need to explicitly tell it to startMonitoringSignificantLocationChanges again because the callback is no longer attached after "freeze drying." And yes, you just need to implement code in didUpdateToLocation once you've re-attached a location handler of some kind once coming back from the suspended state.

This is what I'm going on with my code development right now. As I mentioned before, I'm not quite ready to test this on a device so I can't tell if I've interpreted everything correctly, so commenters, please feel free to correct me (though I've done substantial reading on the topic).

Oh, and if by some stroke of bad luck, you release an app that does what I want mine to do, I might cry :)

Good luck!


If the application is evoked from suspended state as a result of location change application will launch in background state.

All the objects will be live and you will recieve location update in the existing delegate.