Our concern is specifically about NSURLSession background sessions. We are starting (I'd say in the past 4 weeks) to have reports from users that various POST operations that happen via background sessions using uploadTask(with:fromFile:) are not completing successfully. We have an app-specific toggle that lets us disable the use of background sessions; when the users flip that toggle and now start using standard sessions only, their POST requests succeed. FWIW, though we originally were using Alamofire, I rewrote our code to use NSURLSession directly last week, and we continued to have users who report upload issues. This suggests to me that we have a deeper issue/regression for some users and/or devices that use background sessions. Thus, I am wondering if, for example, a mis-use of the Caches vs the Temp directory on a device with storage constraints, for example, could explain this behavior. Also note that we use background sessions for all POST operations because we want them to continue even if the user backgrounds the app. For example, the user sends a chat message then immediately backgrounds us; we want that to complete successfully, so we do all chat POST operations via background sessions. Perhaps using background NSURLSession while the app is foregrounded is itself mistaken?

I hit this same problem too. Mine is coming via a XIB not a direct object invocation

It appears that this is the method that returns "en": [NSLocale currentLocale].localeIdentifier Normally it should return something like en_US, but we now have two users for whom this value appears to only return en and for which localizations are not working properly. The first user apparently reset his phone and got things working. The second user has shown us a screenshot of his phone and it does appear to show "English -> United States" in his settings.

Thank you for this detailed response! The scenario I am trying to solve is simple: in my actual app, each row contains an Image that has data we need to load remotely, just like an AsyncImage. Because we support iOS 14 we cannot use AsyncImage, so in our implementation we have a load method that is invoked in an onAppear block. It appears that Apple's implementation of AsyncImage has no such method exposed, and so the network operation must be triggered in the constructor? If we have a list of many thousands of items, but only a dozen are shown onscreen, I assume that SwiftUI is smart enough to only construct what it needs (plus a few extra above or below what is shown), vs constructing thousands all at once and expecting the code to use something akin to onAppear to figure out when to actually start initializing? Thanks!

Apple has historically not shipped APIs that are blocking -- if so, they are marked as async or include some kind of callback. As a result, I believe that this indicates some kind of problem with the operating system and potentially a bug that should be reported to Apple...?