Is sessionSendsLaunchEvents=NO safe in NSURLSessionDownloadTask?

I am downloading a file at the user's request (hence, starting the download in the foreground). The download is quite large (1.2GB) and so the user may well close the app and get on with doing something else while the download is going on.


My app doesn't need to do anything with the downloaded file once it has finished arriving, other than to move it into the right place. From the app's point of view, this can be done next time the user opens it. From the app's point of view, there is no point in the system's launching the app into the background specifically in order to do this. From iOS's point of view, it saves resources not to launch an app unnecessarily. Moreover, there is the disadvantage of having a hard-to-test code path involved in the "silent launch in order to move the file into place". I like testability!


But before taking the decision to set

sessionSendsLaunchEvents=NO
in
NSURLSessionConfiguration
, I need to know what the likely consequences are. Will
nsurlsessiond
hold on to the downloaded file until the user opens my app again
– perhaps the same time tomorrow – or is it likely to throw the file away, so that the whole download ends up needing to be done again?


I can't find any documentation about this, which may be me, or may be the documentation. But any guidance will be appreciated. I know that this is meant to be an implementation detail, but in this case it does make a definite difference.

Accepted Reply

I can't find any documentation about this …

That’s because the documentation tends to focus on the behaviour that’s guaranteed, and there’s nothing guaranteed here. Imagine, for example, if you set up a download for a huge file and then the user never ran the app again. Should the system keep that download around for the next year? Clearly that’s less than ideal, but the process for cleaning up such downloads is very likely to change over time.

The current implementation puts downloads into the Caches directory, and thus they get cleaned up via the standard mechanism used to clean up caches when the device runs low on disk space.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Replies

I can't find any documentation about this …

That’s because the documentation tends to focus on the behaviour that’s guaranteed, and there’s nothing guaranteed here. Imagine, for example, if you set up a download for a huge file and then the user never ran the app again. Should the system keep that download around for the next year? Clearly that’s less than ideal, but the process for cleaning up such downloads is very likely to change over time.

The current implementation puts downloads into the Caches directory, and thus they get cleaned up via the standard mechanism used to clean up caches when the device runs low on disk space.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Yes, indeed – I do appreciate the difficulty you have, because if you tell us enough about the implementation for us to understand what you mean by the feature, we tend to go and assume that this is part of the contract, with all sorts of recriminations when it turns out that it wasn't. So you're damned if you tell us anything and damned if you don't!


But thank you for a clear explanation of the general idea. "Same as other caches, for now at least" is a reasonable policy and it is possible for us to think about our app with that in mind (though not assuming it to be a contractual guarantee).