NSURLSession Resume Rate Limiter insight

I'd like to share some of the finding with regards to the NSURLSession resume rate limiter covered in this post, since the discussion is locked there.

NSURLSession’s background session support on iOS includes a resume rate limiter. This limiter exists to prevent apps from abusing the background session support in order to run continuously in the background.

While the original post gives the overview of the rate limiter, it leaves some questions open. I did my own test to get those answers and build knowledge about rate limiter work.

Here is the summary of the findings made on iPhone 7 running iOS 12.4

1) nsurlsessiond's rate limiter increases the request delay when the app gets launched/waked up by nsurlsessiond to process a response to the background request. The request delay increases before the -[UIApplicationDelegate handleEventsForBackgroundURLSession:completionHandler:] call. Then nsurlsessiond doubles the delay for every subsequent launch / wake up caused by a response to a background request. The delay starts with 60 seconds. nsurlsessiond resets the delay when the user opens the app. Logs observed in Console app, in this case, look as follows

default 22:02:42.313511 -0800   nsurlsessiond   Set request delay for  to 60.000000
default 22:03:53.193396 -0800   nsurlsessiond   Set request delay for  to 120.000000
default 22:04:52.505582 -0800   nsurlsessiond   Set request delay for  to 240.000000

2) When the app transitions to the foreground, the nsurlsessiond resets the request delay for the app. Here is how the log looks like.

default 21:11:37.137450 -0800 nsurlsessiond Resetting request delay for

3) Background requests that get started in the foreground and background application states and get completed while the app is still running do not increase the request delay on the nsurlsessiond side.

4) When the app runs in the background with an active background task that keeps the app alive, the background requests get completed just like the ones started when the app is in the foreground state. The log, in this case, looks as follows.

default 22:33:59.148845 -0800 nsurlsessiond Task .<89> has not requested a begin delay

5) NSURLSession with NSURLSessionConfiguration.sessionSendsLaunchEvents set to NO, does not cause the request delay, as it does not need to wake up the app to process responses.