Same problem here with Xcode 12 GM, iPhone X, iPhone SE 2nd generation, iPhone XR ... taking long time to start debug session on real devices ...annoying!!! Apple, solve this please!!

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.

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.

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.

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

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.

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"

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.

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.

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.