Thank you, Quinn. I appreciate the response. The article is a good writeup and helpful. It makes sense why the power and data management policies are intentionally opaque. For additional context, the app is in market and we do refine our implementation and behavior for uploads based on our observability metrics and customer feedback. We switched to primarily background uploads from foreground uploads about year ago because we could see in our analytics that people were starting uploads and then backgrounding the app, regularly. We would restart the uploads if they returned but that could lead to uploads processing in short bursts. Moving to background uploads on balance improved our reliability; however, we have had recent reports of people getting into a wedged state where uploads cease working. After investigation, we've traced it the issues outlined in this post. Sharpening my questions a bit: The behavior that surprises me the most is that a task which was created (or resumed) while the app is in the foreground and reporting isDiscretionary = false can be blocked by Energy Budget or Data Budget Policy even while the app remains in the foreground. This seems to be at odds with the documentation for the field. Is this expected? It looks like we could reduce pressure on the system by using resumable uploads and not partitioning large files and sending them as separate requests. Is there an effective maximum size of supported uploads? For example, we've seen memory issues using a file mapped Data instance when segmenting large files whereas an InputStream was effectively unlimited. My overall, take away so far is that if we want to be able to take responsibility for quality of service and support backgrounding the app, we should take a closer look at BGContinuedProcessingTaskRequest for the places where we can use it which would let us model the actual network work as foreground requests.