So, the double calling issue might have been happening because I was accidentally recreating URLSession when foregrounding as opposed to when re-launching. I still can't fix the progress reporting, though. Even with resuming one or all tasks, lots of files just get skipped entirely. I tried using the .progress property of the URLSessionTask and that works well for backgrounding, but the Progress object does not get set up correctly after termination and relaunching, and since it's a read-only property, one can't seem to fix it manually.

I started testing on devices, and on iOS 16 I still see the same double-calling bug, and on iOS 14/15 I still see the same no downloadTask.response bug. If I ignore the absence of a response and keep going, then I do not see the double-calling bug on iOS 14/15, as well as the not reporting all bytes downloaded bug (again, even though I'm resuming the first task). (EDIT: I do see the double-calling bug, I just seem to have to stay in the background for 25 seconds, longer than on iOS 16) On a device, the reporting of progress doesn't continue at all after resuming after background, as opposed to on the simulator where it just skips some files (seemingly the ones that completed their downloads while backgrounded, but that's difficult to be sure about). Disclaimer: iOS 14 testing was on simulator, iOS 15 on device. iOS 16 on both.

Before filing a bug, I'm trying to test on iOS 14 and 15 to see if this is a regression, or not. On iOS 14, I received on didFinishDownloadingTo callback where the task's response and error were both nil, which I also take to be a bug. I'm reading in some places that I shouldn't be testing background tasks on the simulator, is this true? I know you've linked to a guide you posted about testing background sessions multiple times in the past, but the link seems broken (probably due to a change in the structure of the forums). Do you have a current link to that guide? Re: 32247561, is this the bug that's worked around by calling resume() on one of the tasks? If so, that did not help in my case.

I was having issues with bundleID lookups for new apps not working for awhile, but adding &country=US not only returned results, but seemed to have fixed or cached something such that the original query works now, as well.

I guess I should have a question, which is: anyone else experiencing this, or is tab switching working as expected for you?

Same. Bloody annoying since it spams the debug log, but at least it doesn't seem to have a visible manifestation in the UI.

When you open the app in App Store Connect, at the bottom of the App Information tab there's a link to:View on App StoreI copy this and give it to my Maas360 clients. They use it for both the app URL and the app icon URL, and it works.