The documentation at https://developer.apple.com/documentation/foundation/url_loading_system/downloading_files_in_the_background, in the section titled "Use Background Session efficiently", talks about delays being introduced when an app uses background NSURLSessions in a certain way.
It also says that all delays are reset when the app is brought to the foreground.
In the app in question, I have
- a file provider that uses a background NSURLSession exclusively
- a HTTP scheduler that schedules small requests on a local NSURLSession and up- and downloads on a seperate background NSURLSession
Now, what I noticed under iOS 13.1.3 is that - even though the app is in the foreground at all times - delays are added to requests going to the app's background NSURLSession. Here are the timings of one affected request, taken directly from NSURLSessionTaskTransactionMetrics:
{ total: [2019-10-16 18:56:24 +0000 - 2019-10-16 18:56:54 +0000, 29.95 sec], startedAfter: 0.00, redirects: 0, transactions: [1: fetchStart: 0.02, request: 29.02..29.02 (0.00), cloud: 29.02..29.73 (0.71), response: 29.73..29.95 (0.22)] }
- fetchStart is at 0.02 seconds
- requestStart is at 29.02 seconds
That's 29 seconds from the task being to the app's background NSURLSession from actually being performed, on a device that's not under any network load whatsoever.
Now, the app already takes care to schedule as few requests as possible on the background NSURLSession. And according to documentation, the delays are reset and not carried out if the app is in the foreground. Which the app is while the above delay is imposed.
Is there anything else that could be causing these delays? Or anything else that I could do to avoid them? Could the File Provider's exclusive use of a background NSURLSession - in the background - lead to penalties being imposed on the app? Or are these two accounted for on a separate basis?