Does NSUrlSession continue file transfer if the app is killed from task manager?

Question

I have tried various samples from the web (the last one being this one) in order to get a better understanding of NSUrlSession.

What I was hoping to see: file downloads will continue even if the app that triggered them gets killed (for instance by the user through the task manager). However this does not seem to happen.

Is this a configuration issue or does background file transfer not work if the app gets terminated? I thought the whole idea was that iOS will restart the app.

Ailssa

Basic OS: When a task (app in this case) is terminated all resources are recovered by the OS including the IO resources. There is nothing left to receive the data. – Schaeffer

Yes, this should work. You'll be better off posting the shortest complete example of what you're trying so people can see if they can figure out what's going wrong, rather than just asking without code. @Zaph With NSURLSession, if you begin a task on a background session, it's passed to the OS's background transfer daemon to complete. It should, therefore, survive the killing of the app. When the task is complete, the app is restarted by the OS and a notification is delivered to the app delegate so it can pick things back up by reconnecting the session. – Kirksey

@MattGibson The examples are rather long. See the link in my original post. This app creates a background session and starts a file transfer. If the app is terminated it will not restart the download. Zaph's comment is correct and I also got a confirmation on the Apple dev forums meanwhile. – Ailssa

Sorry, not quite sure what you mean by "if the app is terminated it will not restart the download". Can you clarify a little? I'd expect that downloads that had been started would continue in the background if the app is terminated, and that application:handleEventsForBackgroundURLSession:completionHandler: would be called when the download was done (with a session identifier you can use to rebuild the session), restarting the app if necessary. I'm not sure why you'd need to restart a download; it wouldn't have stopped. – Kirksey

I'm basing my understanding on "What's New In Foundation Networking", session 707 at this year's WWDC. Dan Vinegrad seems pretty convinced that an app can crash or be killed and will be woken up to handle completion (around 40m in). He uses the word "killed", but doesn't specifically talk about the user killing the app through the task manager, so maybe that's a special exception? Aha! -- looks like it is an exception. – Kirksey

@MattGibson Good spotting! That's also what I observed. And thinking about it: in one of the talks from WWDC about the NSUrlSession, the speaker says that iOS will respect the task manager, meaning if the app is closed, it will not restart or continue the upload or download. – Ailssa

@Ailssa Yup, makes perfect sense. A deliberate kill by the user is a good hint that the user doesn't want that app doing anything. I'd imagine that the task manager kills the app and also tells the background transfer daemon to kill all the app's transfer tasks at the same time. – Kirksey

Incidentally, looks like the upcoming new documentation is starting to clarify things: developer.apple.com/library/prerelease/mac/documentation/…: now specifically mentions terminating the app from the multitasking screen, and confirms that it will kill background transfers. – Kirksey

@MattGibson Though that's about Mac and not iOS. Should be same on iOS.... – Ailssa

@Ailssa It specifically mentions iOS behaviour under backgroundSessionConfigurationWithIdentifier. – Kirksey

Answer 1

If the system kills your app and your background session has active downloads, your downloads will continue and the system will launch your app when the downloads complete. However, if a user force quits your app, all tasks get cancelled.

Documentation for backgroundSessionConfigurationWithIdentifier:

If an iOS app is terminated by the system and relaunched, the app can use the same identifier to create a new configuration object and session and retrieve the status of transfers that were in progress at the time of termination. This behavior applies only for normal termination of the app by the system. If the user terminates the app from the multitasking screen, the system cancels all of the session’s background transfers. In addition, the system does not automatically relaunch apps that were force quit by the user. The user must explicitly relaunch the app before transfers can begin again.

Gastroenterostomy

The wording seems strange\confusing to me. I don't understand the last 2 sentences. "In addition, the system does not automatically relaunch apps that were force quit by the user." A sentence before that it says that system cancels all of the session's transfers, so why does it say it doesn't relaunch the app? Or maybe it's saying that app is not going to be relaunched to notify it that transfers were cancelled? – Waldenses

Answer 2

No - the app is not relaunched for background downloads when the user has force quit.

The iOS8 documentation for application:didReceiveRemoteNotification:fetchCompletionHandler: says:

Use this method to process incoming remote notifications for your app. Unlike the application:didReceiveRemoteNotification: method, which is called only when your app is running in the foreground, the system calls this method when your app is running in the foreground or background. In addition, if you enabled the remote notifications background mode, the system launches your app (or wakes it from the suspended state) and puts it in the background state when a push notification arrives. However, the system does not automatically launch your app if the user has force-quit it. In that situation, the user must relaunch your app or restart the device before the system attempts to launch your app automatically again.

Folberth

The question has nothing to do with background fetch. – Fescue

Why is this the accepted answer when the question is about downloads and the answer is about push? – Forcefeed