User Profile

Our messaging application with VoIP feature build with Xcode 11 beta 2 and running iOS 13 beta 2 stoped receiving notifications over PushKit while the app is in the background or not runnig. At the same time notifications get delivered fine when the app is in the foreground.The issue with notifications not delivered to a backgrounded app appears to be the system issue as they get delivered to the phone but not passed to the app. The fact that a notifction gets delivered to the phone can be conformed with apsd process logs which appears as follows in our case: Received message for enabled topic 'com.MyAppName.voip' onInterface: NonCellular with payload '{ aps = { ... }' with priority (null) for device token: NOThis is a recent regression in the beta 2, since we could not reproduce it with beta 1.

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.41) 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 followsdefault 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.0000002) 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 for3) 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 delay5) 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.