Hello! I have read most of the "Background Tasks Resources" here https://developer.apple.com/forums/thread/707503 - but still have a few questions that I need clarified.
To provide our context, our usecase is that our user wants to upload files to our servers. This is an active decision by the user to initiate the upload, but we also want make sure the files are uploaded, even if the user chooses to background our app.
If we use a URLSession.backgroundto initiate the uploadTask, I understand that we are passing it of to the urlsession deamon to handle the upload. Which is great, if the user chooses to background our app. But, what if they just stay with the app in the foreground? Will it start uploading immediately? Can we expect the same latency that a standard URLSession will provide? And the potential delay will only occur if they actually background our app.
Also, what happens if a background upload is in-progress and the user enters our app again? Will it gain priority, and run with similar latency as standard URL session?
I.e., can we just always rely on using a background session, or should we kick of a beginBackgroundTask with a standard URL session, and only trigger a background uploadTask if we do not finish the standard upload before getting told we are about to get killed?
A different question. I know there is the rate-limit delay added if we trigger multiple background URL tasks. Does that effect the following use case? We would like to send an additional HTTP request to our servers when the upload is completed, to notify it of the completion, but are we allowed to do that when the app is woken from the background? So, basically calling .dataTask from handleEventsForBackgroundURLSession for example?
I have read most of the "Background Tasks Resources" here
Cool. But there are some network specific ones you should also read:
The first one is probably most relevant to your issue.
Networking Resources has these links and a lot more.
But, what if they just stay with the app in the foreground? Will it start uploading immediately?
I would expect so. However, that’s not guaranteed. The nature of background sessions is that the system gets to choose when to run the transfer, based on its global view of the device state.
IMPORTANT A lot of this stuff is not documented, and deliberately so. These policies are considered to be implementation details. They’ve changed in the past and it wouldn’t surprise me if they changed again in the future. So, when you ask “Will it do X?” the only real answer is “Suck it and see.”
Can we expect the same latency that a standard URLSession will provide?
No. In general, background sessions prioritise device resources and bandwidth over latency. Consider:
- There’s the
isDiscretionaryflag. The docs explain what that does, although I’m not 100% confident that they’re accurate (-: - For standard sessions, the
networkServiceTypeproperty is relevant. AFAIK, background sessions treat all requests as if that was set to.background.
what happens if a background upload is in-progress and the user enters our app again?
At least at one point in time we would boost the priority of a background session when the user brought its app back to the foreground. I don’t know whether that’s still the case.
So, basically calling .dataTask from handleEventsForBackgroundURLSession for example?
I usually recommend a standard session for that sort of thing, using a UIApplication background task to prevent the app from suspending while the standard session request is in flight.
The challenge is that the standard session request may not complete in the time granted to you by the UIApplication background task, so you need an expiry handler to shut it down. What you do after that is up to you, but one option is to retry the request in your background session.
Oh, one last thing about that: Background sessions do support data tasks but with a major: They don’t run if your app is suspended. So if you do end up retrying in a background session, you have to use a download or upload task.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"