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

From the iOS 15 beta 8 notes, this may help: Using dispatch semaphores in an iOS app running in a device simulator on a Mac with Apple silicon running macOS 11 will cause the app to crash. (81783378) Workaround: In Xcode, select Product > Scheme > Edit Scheme, then deselect Run > Options > Queue Debugging > "Enable backtrace recording."

Same issue here :( Has anyone found/heard of workarounds?

Same question here

Same issue here

I am getting this as well. Xcode 14.0.1, running on Monterey 12.6 release (21G115) Does anyone know of a workaround? (Filed this as FB11602587)

I think in my case I found a workaround, and I'm posting it here in case it works for others too - I had SWIFT_REFLECTION_METADATA_LEVEL set to "None" for release builds. Setting this back to the default (All) seemed to do the trick and let appintentsmetadataprocessor extract the info during the archiving step. There's probably a more elegant solution, like telling the compiler to emit reflection data only for the file containing the app intents definition, so if anyone finds this workaround helpful and has a better way to do it, please shout :)

Having exactly the same issue