I have a RealityView that is an earth globe, where I'm adding attachments and also updating how attachments appear, depending on user input. I pass a @Binding var annotations: [MyAnnotation] to my view which has a RealityView as its main body. The annotations are displayed fine using the SwiftUI views defined in the annotations handler, but they do not update when the annotations in that binding are updated. My attachments: handler looks like this: RealityView { ... } attachments: { ForEach($annotations) { $attachment in AttachmentView(attachment: $attachment) .tag(attachment.id) } } I also tried without the $ syntax there. Neither leads to an update of the AttachmentView. Curiously the update handler also isn't called when the annotations are updated. I also tried settings a different .id on the entire thing, but even then it's just using my AttachmentView as initially configured. I'm very puzzled by this and would appreciate help. Am I holding this wrong, or is this a bug?

I'm working on Shared with You support for my iOS / macOS app, and it's working very well on iOS. I am trying to publish a macOS beta that's signed with my Developer ID, but I'm getting the following error: The Shared with You capability is not available for Mac Catalyst Developer ID provisioning profiles. Disable this feature and try again. However, the documentation says that the feature is available on Mac Catalyst. Is this just not available when trying to export for signing with my Developer ID? Is this an inherent limitation and this is only available for builds that are distributed through the App Store or TestFlight?

I'm using Xcode 14 beta 4, on macOS Monterey 12.5, developing a Mac app that's using CoreData CloudKit sync — with my context being configured with two configurations (one for a local cache and one data synced via CloudKit). An issue recently appeared where the app crashes soon after start-up with this message: [threadmgrsupport] _TSGetMainThread_block_invoke:Main thread potentially initialized incorrectly, cf <rdar://problem/67741850> And this stack trace: Thread 1 Queue : com.apple.main-thread (serial) #0 0x000000018b86b5e8 in ___NSAssertMainEventQueueIsCurrentEventQueue_block_invoke () #1 0x0000000105b563a8 in _dispatch_client_callout () #2 0x0000000105b58300 in _dispatch_once_callout () #3 0x000000018b86a2dc in _DPSNextEvent () #4 0x000000018b868e14 in -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] () #5 0x000000018b85afe0 in -[NSApplication run] () #6 0x000000018b82c6fc in NSApplicationMain () #7 0x00000001ae281e98 in specialized runApp(_:) () #8 0x00000001aee10588 in runApp<τ_0_0>(_:) () #9 0x00000001ae88626c in static App.main() () Things work again, if I disable the CloudKit sync by not setting cloudKitContainerOptions on my "Cloud" configuration. Similarly, it works on first install, but reappears on subsequent runs. The code is in a package that's shared with an iOS version of the app, which has no such issues. I also tried going back to previous commits that worked before, and it works again until at some point it stops working again for the same commits. So it doesn't seem to be caused directly by my code, but rather by something that the CloudKit sync is doing. Any help would be much appreciated.

It's great that SPM added support for bundles! I went ahead and added SPM support for a library that I'm working on - https://gitlab.com/SkedGo/iOS/TGCardViewController/-/tree/spm which includes several .xib files and also an en.lproj. This worked well - running both in the simulator and on device. So far so good. Next, I had a look if it's possible to already use this in a TestFlight build. Unfortunately that failed as App Store Connect responded with: ERROR ITMS-90535: "Unexpected CFBundleExectuable Key" ... consider removing the CFBundleExectuable key from its Info.plist and using a CFBundlePackageType of BNDL. Inspecting the built products, I can indeed see that build product of my app contains .bundle for my library (as expected) and digging into that I can confirm that it has a CFBundleExecutable with the same name as the bundle file (without file extension) and that CFBundlePackageType is already set to BNDL. I wonder how to resolve this. Did I miss a step along the way, is this an issue with SPM or is App Store Connect just not ready for this yet?