The transform is set in viewDidLoad. But I can reproduce the problem by setting the transform afterwards as well. The problem with just setting the insets myself is that I don't know where to get the correct values from, as the safeAreaInsets are not updated, which is the problem. Where else might I get the correct safe are insets values from?

override func viewDidLoad() { 		super.viewDidLoad() 		tableView.transform = CGAffineTransform(scaleX: 1, y: -1) } That's all it takes. Instead of CGAffineTransform(scaleX: 1, y: -1) you can also just do CGAffineTransform(scaleX: 0.99, y: 0.99), it has the same effect on the safeAreaInsets not updating.

On what device did you test this? The bug is only relevant on iPhones with notch, i.e. without a home button. I should have clarified that, sorry. The following numbers are from an iPhone 12 emulator, with iOS 14.3. So the behavior is interesting. When the app starts with the UITableViewController as initial view controller, I also get 0 all around for the safe area insets: At load: at load UIEdgeInsets(top: 0.0, left: 0.0, bottom: 0.0, right: 0.0) after transform UIEdgeInsets(top: 0.0, left: 0.0, bottom: 0.0, right: 0.0) layout changed UIEdgeInsets(top: 0.0, left: 0.0, bottom: 0.0, right: 0.0) after rotation: no output, viewLayoutMarginsDidChange is not called. However, if I push to another view controller and then return, upon return: layout changed UIEdgeInsets(top: 143.0, left: 0.0, bottom: 34.0, right: 0.0) after rotation: again, no output I just double checked this on a real device (iPhone XS) and get the same results.

So I just got a reply from Apple to a bug report I filed for this, and it turns out the propagation of safe area insets to a view with a scale or rotation transform is not supported. You have to apply the transform to a view deeper in the view hierarchy or handle it yourself some other way. Bummer, but good to know.

As suggested by https://twitter.com/hunter/status/1513960632059510784 I just deleted my local provisioning profile files which forced Xcode to generate them again and this fixed the issue for me.

Correct! This is a normal call to URLSession.upload(for:from:delegate) while the app is in the foreground, not a background session. The URLSession is created by us, but with the URLSessionConfiguration.default and only with a custom user agent string. Everything else is left as is. I might also add that the server is also our own software. The way it works is the server receives the data until the allowed maximum is reached, then it sends the response and closes the connection, while the network layer is still trying to send the remaining data. But again, I could see in the diagnostics log that the response is received and read.

Yes!

It is not. At least not to my knowledge, and I don't see the "Transfer-Encoding: chunked" header on the server side (I don't know if I would though, or if the framework we are using on the server (Spring Boot) handles that transparently). Would that be a possible solution? If so, how would I enable chunked transfer encoding? I tried to just add the Transfer-Encoding header to the URLRequest, but that didn't seem to do anything.

Interesting, I did not know this header. It seems to do exactly what you would want: give the server a chance to reject the request before the upload of the body is even started. I added the header to the URLRequest, but that did not fix the problem. But that might very well be a problem on the server side. I'm still investigating that. So I guess that would be our best shot? Trying to make our server support this header?

Ok, found the answer: the header view class can also be a UICollectionViewListCell, which provides the exact same mechanism as UITableViewHeaderFooterView.

Thank you for the quick answers! To be on the safe side I had a co-worker test this on his iPhone, and there it worked. So I rebooted mine and tried again, and now it works on mine as well. So false alarm I guess.

One way would be to perform the import in the background in a @ModelActor. Something like this: @ModelActor actor ImportService { func import(data: [Data]) throws { for date in data { let model = Model(/* ... */) modelContext.insert(model) } try modelContext.save() } } This way the import will not block the UI, and the imported data will only be visible in the UI after modelContext.save() is called. I haven't used SwiftData in a real-world app yet, however, so do be careful. For example I don't know if SwiftData will keep the models in memory until save() is called, so you might have to save more frequently. But even then, the UI will not update for every newly inserted model but only when you choose.

For me the option 2 is not working (and option 1 is not really an option as we need to support older iOS versions). I followed the instructions, added the DYLD_FALLBACK_LIBRARY_PATH argument to the Run configuration of my scheme like this: DYLD_FALLBACK_LIBRARY_PATH=/Library/Developer/CoreSimulator/Volumes/iOS_22F77/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 18.5.simruntime/Contents/Resources/RuntimeRoot/System/Cryptexes/OS/usr/lib/swift But the app still crashed, and when it logs the dyld config, it prints this: DYLD_FALLBACK_LIBRARY_PATH=/Library/Developer/CoreSimulator/Volumes/iOS_22F77/Library/Developer/CoreSimulator/Profiles/Runtimes/ So it seems my value for DYLD_FALLBACK_LIBRARY_PATH is just ignored. I checked it a thousand times and don't understand what I'm doing wrong. Is this working for other people too? Edit Found the solution, see comments if you run into the same problem.

Thank you for posting this here! Our app is affected as well and I have been trying to produce a minimal example in a new project all afternoon but failed, just like you said. To add some information: I can crash our app by simply accessing URLSession.shared or URLSessionConfiguration.default (but not by simply accessing URLSessionConfiguration.ephemeral) in the initializer of our AppDelegate.

As I understand the documentation, this is indeed the expected behavior: By using the completion handler, the task bypasses calls to delegate methods for response and data delivery, and instead provides any resulting NSData, URLResponse, and NSError objects inside the completion handler. See dataTask(with:completionHandler:)