In a
post upthread I referenced a post on old DevForums. That link no longer works, alas (for an explanation as to why, see
this post). Someone asked me about the info in the old post so I’ve included it below.
IMPORTANT I’ve edited this for appearance only. I read through the content to make sure that it’s not completely bogus but I made no attempt to bring it up to date. When you read the following, imagine that you’re reading something from Feb 2014, which was when it was written.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
It’s also possible that the task has been paused due to throughput issues. The
NSURLSession background session infrastructure imposes a high-level timeout on tasks with low throughput. For example, if the connection is transferring about 10 KB per second, it gets paused after 30 minutes.
Note The exact throughput limits are not documented, and probably never will be, simply because they are likely to change as the system evolves.
At that point
NSURLSession waits for network connectivity to change before continuing the task, the theory here being that the new network might be faster. In my experience, turning Airplane Mode on and then off again will cause such a paused task to be continued shortly thereafter.
If the server does not support resuming a download this can result in pathological behaviour. Instead of resuming where it left off, the download will resume at the beginning. If the throughput limit isn’t an artefact of the local network but is, instead, a problem at the server end, the new transfer will run at the same speed of the old transfer and thus get paused at some point. This process continues forever.
IMPORTANT Below you’ll find information about what makes a download resumable.
I should stress that this issue only crops up for discretionary tasks, where the system will work away in the background trying to complete the task. For standard tasks the first failure will cause the system to resume your app to tell you about the failure.
Keep in mind, however, that tasks started while your app is in the background are always treated as discretionary.
Obviously this stuff needs better documentation. I’ve filed a bug requesting that (r. 15565034).
It would also be helpful if there was visibility into this issue, both programmatically and for debugging; we already have bugs on file about this (r. 14783761, r. 15090548, respectively) but feel free to file your own bugs with your own suggestions.
The following criteria must be met for a discretionary download to be resumed automatically by a background session:
The scheme of the requested URL must be http or https.
The request’s method must be GET.
The response must be an NSHTTPURLResponse (which should always be the case given the first point).
The response must include either the ETag or Last-Modified headers (or both).
The file to which the task is downloading must be present. This file is managed internally by NSURLSession, so you shouldn’t trip over this case (unless there’s been a cache folder cleanup in the interim).
