As far as I know, removing an app from the App Store does not prevent users who have already installed the app from using it. It only prevents further downloads from the App Store, i.e. new installs or updates. Also, it is against the App Store rules (again, as far as I know) to just publish an update that e.g. only shows a message that the app is not functioning anymore (since apps on the App Store need to be functional). Since you mention a backend: could you just shut that off? Does your app handle that in any way and show a message?

Bug report submitted under FB19401153.

Did you specify a sound file in the JSON payload as explained in the documentation Create the JSON payload?

Interesting. We use UIApplication.shared.setAlternateIconName() in the same way as you describe: the async/await version in a @MainActor annotated method. And we have no problem, neither in Xcode 16.3 nor 16.4. Both simulator and physical device.

All I can say is that Drag & Drop works for me. Depending on the file type, it opens the Photos or Files app, respectively. It does sound like there is something wrong with your installation.

Still crashes for us.

This seems to be related to this problem for iOS Simulators: Xcode 16.4 iOS 18.5 simulator crashes for Apps requiring webkit The crash only occurs when some specific methods are called on WKWebView and some other types. One workaround for iOS simulator was providing a path for libswiftWebKit.dylib via DYLD_FALLBACK_LIBRARY_PATH. I don't know how this would be done in Previews though.

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:)

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.

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.

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.

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.

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

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?

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.