Hi Justin, I have the same trouble but using UIKit. CloudKit can manage mirroring with CoreData everywhere either SwiftUI or UIKit, so i am using the same feature as you do. And now I am stuck because cannot find info how to get CKRecord from my synchronised CoreData Entities. Did you find the solution?

I've found the solution. On the NSPersistentCloudKitContainer we have to simply call persistentContainer.record(for: object.objectID) where object is NSManagedObject

Dear Frameworks Engineer, How can you recommend to resolve conflicts. Does any callback exist when NSPersistentCloudKitContainer finishes sync?

I've tried to implement some code for sharing manually with working CloudKit + CoreData mirroring. I've stuck on the parent records (I have one-to-many relationship and child records need to be shared when parent record is shared) and here is why. I've implemented code that is setting parent records for each NSManagedObject's CKRecord, syncing works well, but it causes huge troubles like: I call my setParentRecords among other places from NWPathMonitor's pathUpdateHandler (literally when internet restored), and fetching NSManagedObjects that's CKRecords if any don't have parent on the server yet. Apple's NSCloudKitMirroringDelegate is doing the same also on internet restore. And my any fetching at this second causes crash of Mirroring. Mirroring do not work since this point and says "probably no internet" each time! I could not beat that problem and I am afraid that will have to implement whole sync by myself, even for privateDatabase just because of such bugs (and no any completion handlers in NSPersistentCloudKitContainer). So, simple fetch crashes whole mirroring until app restarted.

How can I file a bug of this type properly?

I've figured out what happens here. Here is what we must do after leaving share: Leave share Perform sync again (to get new token)! Check if we received leaved share on step 2 at fetching because CloudKit server 50% chance will not return updated state if you will perform step 2 right after step 1. Looks like server need some short time to process updates from step 1, so we have to run step 2 for example in 2 seconds after step 1 (and anyway check step 3 after that as I have no idea if it can update it's state longer than half a second as usually). So, I do not allow to accept any shares until step 3 (check if step 2 fetch contains share deletion) succeeded. If it return deleted share, then it's safe to accept this share again and we will get all updates correctly.

@gilby, Could you solve this problem? Since 1 year, SKProductsResponse is still caching the result and I have to clean build folder, delete derived data and wait 10 minutes each time I want to test SKProductsRequest. It's just a nightmare. @rich, Do you know any new solution for that?

You can disable clipping with help of Introspect for SwiftUI https://github.com/siteline/SwiftUI-Introspect Using it you can get underlying UIKit objects. In your case simply add this to the ScrollView. ScrollView(.horizontal, showsIndicators: false) { //..... } .introspectScrollView { view in view.clipsToBounds = false }

Will also add my SO question I've created earlier. Please upvote to bring more attention. Some newbies downvoted and it prevents the question from being found. https://stackoverflow.com/questions/77227252/swiftui-sheet-never-releases-object-from-memory

Don’t understand what do you mean

It looks like iOS 16 bug. When we have much more users with iOS 17, we are getting this crash report exclusively 100% for iOS 16 users in Crashlytics. Would be nice to have some simple workaround, but this crash is not happening extremely often, so we just live with it, iOS 16 is not that popular anymore.