That's a known issue - https://developer.apple.com/news/releases/?id=06232020a: > Apps that use Swift packages containing resources are not successfully imported. As a workaround, manually remove the CFBundleExecutable keys from the Info.plist files of the embedded resource bundles.

We have the exact same issue with an app update. We tried both Xcode 12.5.1 and Xcode 13.0 RC. It processes fine, and after submitting for App Store review, it goes into "Invalid Binary" state after exactly one minute each time. No details why or what's wrong with the binary.

Did you ever figure out how to solve this? I'm facing the same issue currently.

It appears that the reason is that I'm using the SwiftUI App model for my Mac app, and the init() method of my App subclass is not running via NSApplicationMain. So if other code, such as CloudKit then runs it'll assign the main thread to the wrong queue or thread. I can fix this manually by calling let _ = NSApplication.shared manually in my init() method or by deferring my access to CloudKit / CoreData using DispatchQueue.main.async { ... } calls. Submitted as FB10902789, as a SwiftUI bug.

Okay, I've figured out a few things here, in case someone has similar issues: I was holding it wrong in that there was an issue with changes not being picked up by the binding. After I fixed that, the attachments: handler did get called again. Hooray. The old AttachmentView did stick around though, due to the IDs of my attachments changing when they changed shape. I fixed this by making sure those IDs are stable, and calling content.add(...) again in the update: handler then updated those to the new look. The remaining issues was to get rid of all attachment entities if they disappear from my Binding. I'm not particularly happy with it, but the solution I came up with, was to collect the IDs and then iterate through all entities to check if their IDs are still in my set: let allEntities = Array(content.entities) for entity in allEntities { if let attachmentEntity = entity as? ViewAttachmentEntity, let id = attachmentEntity.attachment.id as? String, !goodIDs.contains(id) { content.remove(attachmentEntity) } } Would love to know if there's a better way to do this.

FWIW, I just encountered the same issue on macOS 14 beta 8.

@tkrosenblatt I just came across this as well. I also can't reproduce it myself. Did you ever figure out what was causing this or how to work around the issue?