Your additional explanation has been incredibly helpful to me. It helped me clearly understand the purpose of BGProcessingTaskRequest and recognize that its behavior on development devices can differ quite a bit from how it behaves in a real-world environment—which actually aligns with what I had been observing. I had also assumed that URLSession would need to be a background session to work properly within that task—but learning that it’s actually better not to use a background session came as a complete surprise. It looks like my implementation can be significantly simplified. I truly appreciate your help—thank you again!

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.

Same here before, but now the xcrun devicectl device info appIcon command succeeds on the following environment. macOS Sonoma 14.1 (23B74) Xcode 15.0.1 iOS 17.0.3 $ xcrun devicectl device info appIcon --device <device_id> --app-bundle-id <bundle_id> --width 512 --height 512 --scale 3 --destination appIcon.png --allow-placeholder true 09:42:00 Acquired tunnel connection to device. 09:42:00 Enabling developer disk image services. 09:42:00 Acquired usage assertion. Application Icon Image Information • Image file written to - <a file path> • Is Placeholder - false • Size • Height - 176.0 • Width - 176.0 • Scale - 3.0 • Pixel Size • Height - 528.0 • Width - 528.0