Indeed, I can confirm it's still happening on 13.3 as well 😟

We've been seeing this too - it's the number one crash in our app currently. I created a thread about it while back here:https://forums.developer.apple.com/message/392520#392520There are also threads about this issue that are very likely either related or the same problem, here:https://forums.developer.apple.com/message/386327#386327https://forums.developer.apple.com/message/401926#401926And there are probably more... I created a DTS request about it a while ago, Apple just refunded the DTS credit for it and pasted some generic copy about using Xcode bug tools to diagnose the (so far locally unreproducable) issue.I really wish someone would look into it because like I said it's the #1 crash in our app, it feels like an iOS bug, and any hints on how it could be worked-around would be super-helpful...

Just to add, our experience matches almost exactly the points you describe, the points which coincide:- It is only happening on iOS13, across all versions of iOS 13 that appear active for our users, from 13.2.0 and up- It's happening to all live versions of our application that support iOS 13 (it is affecting versions that were released before iOS 13 came out, so it's not something we introduced recently)- Though the stack trace includes a lot of scene delegate frames, our app has not implemented a UISceneDelegate, everything still goes through our UIAppDelegate implementation only

Definitely our #1 crash too, by a large margin. Impossible to reproduce using any Xcode tools. We did get in on iOS 13.2 as well, although all recent reports seem to be on iOS 13.3 as you describe, possibly because users on the latest iOS versions have updated.

Have filed radar FB7562386 in case it also catched someone's eye on a tech team.

Have filed radar FB7562386 in case it also catched someone's eye on a tech team.

I think we found a way to work around the issue, and your input was definitely helpful, thanks!.In our case, like in yours, it was related to an input accessory view. In our case, we were adding a property observer to the input accessory's superview in "viewWillMoveToSuperview". Moving this handling to "viewDidMoveToSuperview" instead seemed to fix the crash.We can only assume that since iOS 13.2 something changed in UIKit and some temporary superview was being allocated, assigned the input accessory causing a call to "viewWillMoveToSuperview", but then the input accessory was never added, and the temporary view deallocated, which left a dangling observer, I'm guessing? In any case, once the observer was set in "viewDidMoveToSuperview" instead, where it was sure the input accessory was added to that view, the crashes seem to have gone away.I hope this helps anyone else with this issue!

This seems to have started in the last hour for us (UK), clearly an App Store Connect issue. Some builds go through but others break with this error. Hoping Apple will fix it asap.

I have the same issue. List cells that show up when the app loads have images loaded fine, but as soon as I start scrolling any cells below the "fold" all have blank images. Checking the error code from the phase callback it shows the classic URL "cancelled" error (code 999 I believe?). I suspect this may be a beta 1 SDK bug as it's hard to have a bug in the following, almost literally copied over from the Apple docs:     AsyncImage(url: url) { phase in         if let image = phase.image  {             image         } else if phase.error != nil {             Image(systemName: "exclamationmark.triangle").padding() // the error here is "cancelled" on any view that wasn't visible at app launch       } else {             Spinner().padding()         }     }

For what it's worth, I did this hack in my code to get around this, hopefully temporarily. Not sure if I'd ship it :) but it keeps me moving forward while AsyncImage is either fixed, or I end up finding out there's some gotcha that I'm doing in my code that's causing it to cancel its loads in List cells. Time will tell :) struct AsyncImageHack<Content> : View where Content : View {     let url: URL?     @ViewBuilder let content: (AsyncImagePhase) -> Content         @State private var currentUrl: URL?          var body: some View {         AsyncImage(url: currentUrl, content: content)         .onAppear {             if currentUrl == nil {                 DispatchQueue.main.async {                     currentUrl = url                 }             }         }     } }

Also experiencing this. Earlier today I also filed a radar ID FB9334019 with a sample project (nothing complex, all that’s needed is to make a new project in Xcode and add a Swift Package dependency that references UIApplication.shared). Would love to know if there’s a workaround (aside from using Cocoapods I guess :))

@Goff.Marocchi Your link helped a lot, thanks! If I go into the SPM cache, unlock the files, and add @available(iOSApplicationExtension, unavailable) to all the classes of the cached Swift Package that's failing, then the error goes away. So at least this is a workaround. Obviously if I was using the package in an extension I'd need to annotate specific methods and so on with the same code, but in my case the class-level hack did the trick, as I only used the package in the main app target. I'll do the same as you and raise an issue for Swift Packages in my project that needed this hack in the hope we can spare others this headache.

I started seeing this issue in Xcode 13 beta 1 on the sim, however it did not occur when running on an actual device with iOS 15 beta, so I had assumed it was a beta sim problem. As of beta 4 it has now started happening on the device as well. Worth adding that the app breaks even though it’s a TF and built with Xcode beta 3, which ran fine (on device, as mentioned) before updating to beta 4, so I think it’s safe to assume this is an OS issue and not a toolchain issue.

Same here, beta 5 seems to have corrected the issue.

Seems to be fixed now