Eskimo, sorry to keep obsessing about the limits of NSURLSession background downloading, but could you confirm my experimental results that NSURLSession active background download session limits apply to the total number of active download sessions used by all applications on the device?
I wrote some test apps, and it looks like on an iPhone 6 running iOS 9.0b2 the limit is around 800 active background download sessions. More than that and the time taken to create an additional session starts increasing dramatically. Once there are 850 active sessions it seems to take more than 30 seconds per additional session. The slowdown happens at around 1700 active sessions on the simulator, on both iOS 8.2 and 9.0b2. So there's some difference between real devices and the simulator here.
Please accept my apologies if this is just crazy talk. There seems to be a "memory" effect, where performance of NSURLSession depends on past runs of an app, even if the app has been uninstalled and reinstalled. I tried to account for this, but I might be getting confused by the results of multiple test runs interacting with each other.
But anyway, to test if background download session limits are per-app or per-device, I created 3 separate test apps, each one creating 300 sessions. When I ran all 3 simultaneously, I ran into a big slowdown compared to when I ran the apps one at a time. Presumably because 300 * 3 = 900 total download sessions.
So, as far as I can tell, it seems as if every client of NSURLSession background downloads is sharing the pool of about 800 available active download sessions.
If that's the case, it seems like the best policy for an individual app is to use <100 active sessions, and hope that the other active apps on the device don't combine to exceed the 800 active session budget.
… could you confirm my experimental results that NSURLSession active background download session limits apply to the total number of active download sessions used by all applications on the device?
I'm sorry, I can't answer this. The limits you're hitting are not specified as part of the API contract but rather artefacts of the implementation. The implementation has changed in the past and will change again in the future, and likewise these limits. For example, back in the iOS 7 days, folks started hitting problems at around 50 transfers.
I will say that we strongly encourage folks to use a small number of large resumable transfers. That's the scenario that the API was designed for. Attempting to run thousands of background transfers in parallel will end badly, either due to on-the-device problems like the one you've been investigating or due to horrible on-the-wire behaviour.
Share and Enjoy
—
Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
let myEmail = "eskimo" + "1" + "@apple.com"