Background fetch after app is force-quit

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

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

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

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