I truly appreciate your responses — I wasn’t expecting such a fast and clear answer. Thank you for taking the time to help!
First of all, I'm always grateful for your help, Eskimo, and I’m truly honored to have received a response from you this time.
I want to make sure that you’re doing an end-user-level test here. So, something like:
I’ve confirmed that the behavior of BGProcessingTaskRequest remains the same even when the app is distributed via TestFlight and running in non-developer mode.
I hadn’t considered the possibility that behavior might change in developer mode, so I’ll definitely keep that in mind for future testing.
The behavior here is an intentional choice by the engineering team to work around a very specific (and common) usage pattern. BGProcessingTaskRequests are designed to run when they're least likely to disrupt the user, …
Thank you so much, Kevin — your explanation helped me clearly understand the intended use and behavior of BGProcessingTaskRequest.
I’ve realized that the behavioral differences between a suspended app and a force-quit app are not dependent on BGProcessingTaskRequest, and that task failures can affect future executions.
This insight is extremely helpful in designing the background task implementation for my app.
One possible explanation here is that NSURLSession has its own rule around how it handles background transfers.
In fact, the background processing in my app stops when using URLSession. I’m going to review my app’s workflow in background accordingly.
Additionally, I previously had some doubts about how BGProcessingTaskRequest differs from BGAppRefreshTaskRequest, and your explanation made that distinction very clear.
Once again, thank you all so much for your support. I really appreciate all your guidance.
