Indeed, our current workaround was to create an executable with the same name that exits with 0.

Weird and painful indeed! I have submitted the feedback report (large attachments are being uploaded still). The feedback identifier is: FB15350098. EDIT: The standalone app with C++ worked as expected, I suspect it has something to do with the corpulent nature of our app.

Thank you for checking! We are seeing consistent failure on all devices that our developers are using, and restarting the device does not resolve the issue. I spent a fair amount of time performing a git bisect to narrow down the issue, but strangely enough, we begin seeing intermittent failures the farther we go back in history making it difficult to track down the exact commit that may have introduced an issue. For example, starting the app ~40 times results in a handful of failures where as it consistently fails today. Our RELEASE builds currently work correctly. The issue appears to only occur when installing from Xcode from what we can tell.

Thanks for the quick reply! We are using Xcode Version 15.1 (15C65), but we've seen the issue with 15.4 as well. In addition, the crash is occurring on devices with 17.6.1 and 18.0. The output of otool -L is attached! :D otool-output-.txt

Sure, @rosskimes did you still need it?

@ciceron1, did you find a resolution this? I am seeming a similar issue and it is generating 8k+ warnings when we create the dSYM.

For others, I resolved this issue by: Rewrite my own version of the synthesized Bundle.module SPM provides and adding Bundle.allBundles.first(where: { $0.resourceURL?.pathExtension == "app" })?.resourceURL as a candidate location for the resource bundle. Adding a python script to remove the duplicate bundles as a build phase.

This does not appear to be resolved in Xcode 14.3.

I'd love for this operation to be O(1) like itemIdentifier(for:) - https://developer.apple.com/documentation/uikit/uicollectionviewdiffabledatasourcereference/3182924-itemidentifier: This method is a constant time operation, O(1), which means you can look up an item identifier from its corresponding index path with no significant overhead. I fear, perhaps unnecessarily, that snapshot() is an O(n) operation meaning retrieving the section identifier turns into an expensive operation. Can someone from Apple chime in here?