also interested in this. The apple docs tutorial cannot be followed, because my App Store connect looks different. Presumably because the app was not yet submitted for review.

Thank you for the tip. The Info.plist did indeed contain a reference to NSExtension. However, having deleted it, I now get the following build error: Couldn't load Info dictionary for DVTFilePath:0x6000000b42a0:'/Users/userName/Library/Developer/Xcode/DerivedData/appName-dgsfediuxlxwolgiudftjdxvvemi/Build/Products/Debug-iphonesimulator/appName.app/Watch/appName.app' Deleting derived data did not fix this error.

After a bit more testing, the build only succeeds if I FIRST build for watchOS, and SECOND for iOS. Otherwise, iOS build returns the error: .../Xcode/DerivedData/AppName-dgsfediuxlxwolgiudftjdxvvemi/Build/Products/Debug-watchos/AppNameWatch.app: No such file or directory. I suspect this is related to how the iOS and watchOS targets are related to each other. Building for a physical iOS device fails every time.

I found the issue: for some reason, the watchOS target was missing from Target dependencies of the iOS target. Solved!

I spoke too soon. The issue started appearing again. It does not matter whether UICloudSharingController is invoked using UIViewController or UIViewControllerRepresentable. It looks like I cannot remove the "solved" badge from this comment, so I guess I will create a new post.

It could be related. I opened a DTS and Apple confirmed my issue as a known bug with high priority. In your case, the console output could be informative - you should double-check that your bundle ID is set correctly throughout the app.

Check out SWCollaborationView. It's not working for me because it does not appear to be compatible with SwiftUI. But if you're using UIKit, SWCollaborationView can replace UICloudSharingCntroller. I can confirm the share goes through even on subsequent attempts.

finally. I really need this fixed. I'm getting THOUSANDS of these warnings with every run. It's ridiculous.

Using .filter seems terribly inefficient. Can you try comparing the load speed with a large number of files? Something tells me that changing the fetchRequest predicate (rather than evaluating the results) should be much faster.

Thank you. We came up with a similar workaround, wherein we force refresh the chart using the .id() modifier when the user changes visible domain. Unfortunately, the loss of animations makes these workarounds unsuitable for production. I look forward to an official bug fix to this.