I can confirm that this bug is fixed on MacOS 27.2 and will be closing the feedback.

We are at MacOS 27.2 and I'm still waiting for a fix.

I'm getting similar error on macOS Tahoe 26.0 running Xcode 26.0. This used to work when my Mac was running beta versions of macOS 26 and Xcode 26. Now, only this error: Error: assetsUnavailable(FoundationModels.LanguageModelSession.GenerationError.Context(debugDescription: "Model is unavailable", underlyingErrors: [])). Tried to change region to US, language to English, Siri language to English, no changes.

Bug still not fixed on RC version of watchOS 11 running on AW S8: [WCFileStorage persistOutgoingFileTransfer:] error serializing file transfer <WCSessionFileTransfer: 0x14d2a8d0, session file: <WCSessionFile: 0x14dfcbd0, identifier: DCDDB467-B718-4A54-82EB-F9D96587E77D, file: /var/mobile/Containers/Data/PluginKitPlugin/0E6EF953-0A18-42AE-907E-BF786E3D8B19/Documents/blob.data, hasMetadata: NO>, transferring: YES> due to Error Domain=NSCocoaErrorDomain Code=4866 "Caught exception during archival: This object may only be encoded by an NSXPCCoder.

Also having the very same problem here with my app: -[WCFileStorage persistOutgoingFileTransfer:] error serializing file transfer <WCSessionFileTransfer: 0x17dbe7d0, session file: <WCSessionFile: 0x17dc8190, identifier: 897CD06F-7EE0-4B9A-9411-4A42F4D1BEDB, file: /var/mobile/Containers/Data/PluginKitPlugin/68629D41-4733-420A-842E-48A2532FAE56/Documents/blob.data, hasMetadata: NO>, transferring: YES> due to Error Domain=NSCocoaErrorDomain Code=4866 "Caught exception during archival: This object may only be encoded by an NSXPCCoder. The file arrives at the phone but the didFinishFileTransfer on watch's delegate never gets called. Because of this, the files are kept in queue and keep being synced to phone app repeatedly consuming watch battery. Also happens on simulator. iOS 17.5.1 watchOS 10.5.

I managed to find the answer to my own question after some trial and error, and I'm posting here the information in case someone else bumps into the same problem. This is the build icon URL that comes inside the response of v1/builds/{id}/icons request to AppStoreConnect API: https://is4-ssl.mzstatic.com/image/thumb/Purple126/v4/96/d8/9e/96d89ef8-13cb-8b09-8647-301d410b1807/AppIcon-0-1x_U007emarketing-0-5-0-85-220.png/{w}x{h}.{f} Don't make a GET request to this URL as-is because it won't work. You will get a 404 not found HTTP error. Make theses changes to the URL: replace {w} with the value (INT) that comes in attributes->width replace {h} with the value (INT) that comes in attributes->height replace {f} with ".png" as most (if not all) icons are PNG files Applying this 3 changes to the above URL, we get: https://is4-ssl.mzstatic.com/image/thumb/Purple126/v4/96/d8/9e/96d89ef8-13cb-8b09-8647-301d410b1807/AppIcon-0-1x_U007emarketing-0-5-0-85-220.png/1024x1024bb.png Copy and paste this URL to your browser and voilà! You've got the build icon ;-) The need for this replacements is not documented on AppStoreConnect API online documentation.

Adding an example of a response that comes from this endpoint: ▿ BuildIcon type : AppStoreConnect_Swift_SDK.BuildIcon.Type.buildIcons id : "OWE5Y2Y3NWItMTYwNS00ZTljLTkxYzItOTNhYzRkYTg3MjU5IEFQUF9TVE9" ▿ attributes : Optional ▿ some : Attributes - name : nil ▿ iconAsset : Optional ▿ some : ImageAsset ▿ templateURL : Optional - some : "https://is4-ssl.mzstatic.com/image/thumb/Purple126/v4/96/d8/9e/96d89ef8-13cb-8b09-8647-301d410b1807/AppIcon-0-1x_U007emarketing-0-5-0-85-220.png/{w}x{h}bb.{f}" ▿ width : Optional - some : 1024 ▿ height : Optional - some : 1024 ▿ iconType : Optional - some : AppStoreConnect_Swift_SDK.IconAssetType.appStore ▿ links : ResourceLinks - this : "https://api.appstoreconnect.apple.com/v1/buildIcons/OWE5Y2Y3NWItMTYwNS00ZTljLTkxYzItOTNhYzRkYTg3MjU5IEFQUF9TVE9"

Yeah, I'm looking forward to an API endpoint that returns the app ratings (1 to 5 stars) with territory, app version and create date fields at least. Currently only reviews endpoint is available and it's partially useful because it doesn't picture the whole app performance.

Confirmed that Xcode 13.3.1 does not solve the "LLVM ERROR: out of memory" when archiving and when error log reports "Embedding bitcode".

Can't say if or when bitcode will become mandatory, but I hope Apple fix this before making bitcode mandatory. Google bitcode - there are some great docs and articles about it. Please share if the tip has helped you.

Hi there! I'm my case, Xcode 13.3 was breaking with the "LLVM ERROR: out of memory" when archiving. Reading the error log, I've found something interesting: "Embedding bitcode". Well ... bitcode generation is optional. So I've disabled bitcode for that target: Build Settings -> Enable Bitcode = No. And that's it! After turning off bitcode, Xcode 13.3 was able to archive with no more "LLVM ERROR: out of memory". So search for "Embedding bitcode" in your Xcode's error log. If you find it, this is the cure ;-). If not, sorry, can't help you.

Hi there! I'm my case, Xcode 13.3 was breaking with the "LLVM ERROR: out of memory" when archiving. Reading the error log, I've found something interesting: "Embedding bitcode". Well ... bitcode generation is optional. So I've disabled bitcode for that target: Build Settings -> Enable Bitcode = No. And that's it! After turning off bitcode, Xcode 13.3 was able to archive with no more "LLVM ERROR: out of memory". So search for "Embedding bitcode" in your Xcode's error log. If you find it, this is the cure ;-). If not, sorry, can't help you.

Same issue here when archiving. Xcode 13.2.1 was working fine. Xcode 13.3 betas were breaking with the "LLVM ERROR: out of memory" error. Xcode 13.3 final didn't fix this. Message asks to to submit a bug report and include project. Can't include project.