Background fetch after app is force-quit

Hello!

Can someone please confirm whether or not an app will trigger background fetch after it has been force-quit by the user?

Currently my app works performs background fetches correctly when it has been backgrounded, but after force-quitting the app it stops fetching.

Specifically I am referring to scheduled background fetches, not fetches initiated by notifications - although I am interested to know if that would be an alternative.

I've tried searching online and there's a lot of confusing and contradictory information about this - including old Apple documentation that explicitly says it will not launch, however that documentation has since been removed. The new documentation does not explicitly mention the force-quit scenario.

Can anyone please confirm?

Thanks!

Can someone please confirm whether or not an app will trigger
background fetch after it has been force-quit by the user?

It will not. The system interprets this gesture (removing your app from the multitasking UI) as a strong indication that the user doesn’t want your app running. The system will not give the app background fetch time until after the user manually launches the app again.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"
Thank you for the quick response!

Does that mean there is no way for any background activity to occur in the app after the user has force closed the app?
Both fetch time and background/silent notifications (using "content-available") won't work?

(It appears that when the device is restarted that the "has been force closed" flag gets reset for apps - is that correct too?)
I'm facing the same problem as you mentioned @brucefromfortitude valley.
Hope the system doesn't allow us to do such background tasks when the user forcefully kills the app.

Regarding silent notifications, using content-available, it might work I reckon. I tried achieving it, received notifs even when the app is in killed (quit) state, with 'content-available'.

Both fetch time and background/silent notifications (using
content-available) won't work?

Correct.

Does that mean there is no way for any background activity to occur in
the app after the user has force closed the app?

Not quite. Certain background execution modes will relaunch an app in the background even if the user has removed it from the multitasking UI. I don’t have the exact list handy, and it’s changed over time, but it definitely does not include background fetch or silent push.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"

Then how does whatsapp do this?

I tried this:

  1. Send message to phone with killed app
  2. Disabled network
  3. Launched app (not through notification)

result:

Opened app contained new message. So the app must have processed at least save some data from notification. Which means some background activity needed to occur even after app has been force closed.

Then how does whatsapp do this?

I’m able to comment on apps from other third-party developers.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

I tried this: Send message to phone with killed app Disabled network Launched app (not through notification)

I don’t know how whatsapp does this but, you could achieve what you are describing by implementing Notification Service Extension (it will be triggered when a notification comes in, regardless of the app state).

Then you can acces the notitication content, do network requests to your backend or store stuff locally.

You could store data using App Groups so then when launching your main app you could access that information, previously stored from the extension, without network.

Hi @eskimo !

I'm adding to this thread as there is still a question I cannot figure out the answer to.

I've watched the "Background execution demystified" session, which was great, as well as your post on iOS Background Execution Limits but I couldn't find any mention of this.

In the session, Roberto mentions that

... when the system determines which apps to run, it constrains to the set of apps that are still visible in the App Switcher.

I understand that an app that has been manually terminated by the user via the App Switcher is prevented from being launched in the background since the user has given a clear signal that the app should not run. But what about other reasons the app might be fully terminated, that were not triggered by the user?

I'm thinking of crashes (both foreground and background), ANRs and other terminations by OS watchdogs and a suspended app having its memory reclaimed by the system.

Will those scenarios be treated the same as if the user manually terminated the app, or will they be treated as if the app was still suspended?

Thanks you, Åke

But what about other reasons the app might be fully terminated, that were not triggered by the user?

I'm thinking of crashes (both foreground and background), ANRs and other terminations by OS watchdogs and a suspended app having its memory reclaimed by the system.

These don’t put your app into the force quit state.

What does “ANR” mean in this context?

Will those scenarios be treated the same as if the user manually terminated the app, or will they be treated as if the app was still suspended?

You’re missing a point here. Termination isn’t the same as suspension. There are four state to think about:

  • Running

  • Suspended

  • Terminated

  • Force quit

Only the last one prevents future background execution.

So, when you say “will they be treated as if the app was still suspended?”, the answers is definitely “No.” Rather, these all put your app into the terminated state. The key difference between the two is that, in the suspended state, your process continues to exist, which makes resume a lightweight operation, whereas in the terminated state your process is destroyed, meaning that the system has to relaunch your app, which is a much heavier-weight operation.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

These don’t put your app into the force quit state.

I didn't know force quit was a properly defined lifecycle state, that's good to know!

What does “ANR” mean in this context?

"App Not Responding", or in other words a hang long enough to trigger the watchdog. Perhaps the term is mostly used for Android, but I believe the mechanism is similar for iOS? Other OS terminations I was considering include excessive CPU usage.

You’re missing a point here. Termination isn’t the same as suspension

I know this. What I meant was if the checks for background mode would consider a terminated app in the same way as a force quit app. Now that I know about the force quit state it makes sense that they are treated differently. Thanks for the clarification!

It begs the question though - are there any differences between how background modes treat terminated and suspended apps? As you say a full launch is much more expensive than a simple resume. Does this mean a terminated app is less likely to be started for background execution than a suspended app?

Åke

"App Not Responding"

Well, that’s new to me. I’ll see you that and raise you a SPOD (-: Although not on iOS, where there’s nothing to spod.

Anyway, on iOS and its child platforms, watchdog terminations are treated like crashes.

Does this mean a terminated app is less likely to be started for background execution than a suspended app?

I’m not aware of any iOS background execution subsystem that works that way. Once a subsystem has decided that your app needs to be running, it’ll do whatever it takes to get it running.

One related, but definitely not the same, factor is the amount of memory you use when suspended. When iOS needs to recover memory, it starts terminating suspended processes, and it definitely prioritises the ones using the most memory.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hi

When a user kills the app it can be woken up but needs some preparation URLSessionCOnfiguration shoub be specifically configured , also you shpuld use func application(_ application: UIApplication, handleEventsForBackgroundURLSession identifier: String, completionHandler: @escaping () -> Void), and delegate for background fetch. Happy coding

Background fetch after app is force-quit
 
 
Q