1

I am working on an app that, among other things, provides alarms in emergencies. Users can toggle a setting to have alarms be put through even if their iPhone is muted, but this service has another hurdle to leap: when the app has been force quit, it cannot receive (content-available) notifications until the app is relaunched by the user.

There is a geofencing event in place which buys me some processing time even if the app has been force quit, and in that time, I would like to check if such a block is in place, and if so, request the user to open their app again, and not aggressively force-quit in the future. (Many people still think it's just a way to keep things clean, even though it actually costs you battery life to not just leave apps in the background)

SO THE CORE OF THE PROBLEM: I need an (API call? Something else?) that will tell me whether the app is in such a 'force quit, cannot receive notifications' state, assuming that I do have processing time to do this check.

Anything is welcome, I have not been able to find proper Apple documentation on the notifications block.

Thank you very much.

Merijn van Tooren
  • 23
  • 3

1 Answers1

0

While there is no API I am aware of to find state after, you can infer the state just before the application is terminated, and record that.

Code

applicationDidEnterBackground

will be called when an app has received a terminate signal.

More Info

This question describes what lifecycle functions to use, and

Community
  • 1
  • 1
rocket101
  • 7,369
  • 11
  • 45
  • 64
  • I've looked into events like that before, but it turns out that when the app is force quit from the background, there is no event. It's a silent kill in that situation. – Merijn van Tooren Jul 04 '16 at 13:13
  • To be more specific, it's a silent kill when the app is suspended. I'm afraid that's still something I want to account for, though, since even a suspended app can receive notifications, but a force-quit-ed one cannot. – Merijn van Tooren Jul 04 '16 at 13:20