This was later resolved with Apple, but required getting in direct touch with support.

Same issue here.

On further inspection, the following console message appears when this issue happens for the first time: CoreDataCloudKitShare[3672:1242159] systemSharingUIDidSaveShareBlock received error: <CKError 0x28314d8c0: "Server Record Changed" (14/2004); server message = "client oplock error updating record"; op = 134D57570A63DF3A; uuid = 8F070F8B-0AC0-4FFE-A52D-154BCBF3196C; container ID = “containerID> Where containerID is the CKContainer ID, like “iCloud.com.company.samples.CoreDataCloudKitShare”. The message does not appear on subsequent attempts to add more people.

On further inspection, the same problem also manifests in other samples which use CoreData+CloudKit sharing, for example: https://www.raywenderlich.com/29934862-sharing-core-data-with-cloudkit-in-swiftui The problem does NOT appear in samples that use pure CloudKit, such as: https://github.com/apple/sample-cloudkit-sharing This leads me to suppose there is something weird going on between Core Data and UICloudSharingController.

Submitted as FB11623246

A bug report was submitted as FB11623246

Same issue here. Apple pls fix!

You could measure the offset of the ScrollView content and store it using Preference Keys. Then if offset > 0, it means the user scrolled. So, if offset > 0 && leadingBool == false means the ScrollView is partially scrolled. So you can do whatever you need. PS in reality I guess you will scroll x to the negative, so it will be < 0.

As of iOS 16.0.3, this issue appears to have gone away when using the Apple sample app. I am still using the same downloaded code, so a fix was possibly made by Apple on CloudKit side of things. After investigating, I still encountered the issue when invoking UICloudSharingController using UIViewControllerRepresentable (like in the RayW sample code). The issue does not appear (anymore) when invoking UICloudSharingController using UIViewController (like in the Apple sample code).

This is now confirmed by Apple as a known bug with high priority. A detailed, up-to-date post is kept at SO: https://stackoverflow.com/questions/73888519/uicloudsharingcontroller-does-not-work-for-core-data-with-cloudkit

I tried to train the model programmatically in a Swift Playground. This process also failed and returned the following error (I have no idea what it means). Training on a smaller subset of the dataset succeeds. remoteProcessWasInterrupted Error: ["ThreadID": 1278902, "ThreadCrashed": 1, "StackFrameDictionaries": <__NSArrayM 0x600001fe0570>( {     StackFrameModule = vImage;     StackFramePC = 7223916652;     StackFrameSymbolName = "__ERROR_Buffer_Write__Too_Small_For_Arguments_To_vImage__CheckBacktrace"; }, {     StackFrameModule = vImage;     StackFramePC = 7223916524;     StackFrameSymbolName = "_vImageDebug_CheckDestBuffer"; }, {     StackFrameModule = vImage;     StackFramePC = 7223913756;     StackFrameSymbolName = "_vImageConvert_AnyToAny"; }, ... // more fields follow ) ]

I struggled with this a year ago. In the end I restructured my model so it works without unique constraints. For example, you may have a many-to-many relationship between entities Color and Animal (an animal may have multiple colours, and vice-versa: a specific colour may be found on various animals). Without unique constraints, you can fetch animals by colour like this:     if colorFilter != .noValue {       // any animal where color in colors relationship contains value       predicates.append(NSPredicate(format: "ANY colors.color == %@", colorFilter.rawValue))     }

same

I still have this issue. When working with Map() and MapAnnotation(), I get swamped by console prints and purple warnings. Apple please provide a fix or advice!

Same problem here. I'm struggling with extracting NavigationPath() into a separate class using @Observable. When this class is marked as @Observable, typing NavigationStack(path: viewModel.path) {...} results in error: Cannot convert value of type 'NavigationPath' to expected argument type 'Binding<NavigationPath>' Variations like $viewModel.path or viewModel.$path do not work either. The only "working" solution is: var body: some View { @Bindable var bindable = viewModel NavigationStack(path: $bindable.path) {...} } But this is very hacky.