I've found the source of my issue and thus resolved it. In my method that adds my domain models to the sync engine's state as PendingRecordZoneChanges, I was mapping my model's IDs to a CKRecord.ID's record name, but I forgot to include the zoneID in the initializer for the record ID. This is what caused the sync engine to continuously send sync events. My guess is that because my pending changes did not include the zone ID, the local and server records were considered different and thus the engine would keep trying to sync. Curiously, it still populated in the proper zone when I checked the cloudkit console.

Some more information on this issue: After some additional troubleshooting, one thing I did forget to do is to update the serialization state in the .stateUpdate event case in handleEvent(_event:CKSyncEngine.Event,...) method. However, even after fixing this where I cache the serialization state and set our local state to that new state, I am still encountering the issue where the sync engine continues sending the next record zone batch. No properties are being saved on the record between syncs either.

@Vision Pro Engineer Appreciate the suggestions - it seems that it was a combination of items mentioned in your 1st and 2nd suggestion. How I set up this demo app is that I have some core app model state struct that keeps track of various states for use in SharePlay. immersiveSpaceDisplacement did give me the right idea in which it mentions that for a single person in immersive space, the origin is at their feet and when another person joins via SharePlay, the group immersive space that gets created will offset that origin to some shared relative location. This new shared origin is where the model is initially located. When a 3rd person joins, the shared origin is again displaced to account for this new participant, but I was not updating the transform/location for the participants, so the new participant was seeing the 3d model offset from where it should be. I'll need to do some more testing to see if the core app model state needs to update the positions for the original 2 participants or the new participant, but for now I simply have it so that new participants joining will reset the model to the shared origin each time (and thus is a requirement for my feature to have everyone join first before collaborating on the 3d model). Thanks again for your help!

@Vision Pro Engineer Thanks for replying, I was taking a look at that earlier today and it looked promising, but as I thought about it I wasn't exactly sure how to apply it. I know immersiveSpaceDisplacement can be used to calculate the user's origin (as if it were a solo immersive space) but if I place an entity in a shared immersive space's origin, it should appear in the same relative spot for everyone anyway right? Would it potentially be an issue with placing the entity while users are still entering the group/shared immersive space? i.e. 2 users load in and the model has been placed at the same time and then a 3rd user loads into the space, the model might get de-synced there? In theory though, how should I best use immersiveSpaceDisplacement to place entities such that they appear properly in relation to everyone? Additional context as well, before I was more familiar with RealityView and RealityKit, I used to reload the RealityView entirely when swapping models, but now I simply add and remove children from a container entity that I keep reference to in my app model. The old implementation with constant reality view reloading actually did keep the entities in sync, so maybe there's something weird with how I keep track of the container entity? Thanks again for the help!

There is an eventChangedNotification on NSPersistentCloudKitcontainer. You can add a notification/listener to your view/Observable class and re-fetch data like so: import CoreData import SwiftData import CloudKit @Observable class ListViewModel { var cloudkitNotificationPublisher = NotificationCenter.default.publisher(for: NSPersistentCloudKitContainer.eventChangedNotification) func handleCloudkitNotification(_ notification: NotificationCenter.Publisher.Output) { if let userInfo = notification.userInfo, let event = userInfo[NSPersistentCloudKitContainer.eventNotificationUserInfoKey] as? NSPersistentCloudKitContainer.Event { if event.type == .import { // fetch entities/models here } } } } And then in your view, you can attach an .onReceive(_:) modifier to your view, passing in the publisher var body: some View { VStack { // my list here } .onReceive(listViewModel.cloudkitNotificationPublisher) { publisher in listViewModel.handleCloudkitNotification(publisher) } } More information can be found here: https://fatbobman.com/en/posts/coredatawithcloudkit-4/#checking-network-synchronization-status and here: https://developer.apple.com/documentation/coredata/nspersistentcloudkitcontainer/3618808-eventchangednotification

I appreciate the detailed response and suggested work-around! Could you confirm the following statements I've concluded based on your reply: Scene preference is only applied to windows opened before the session is received. Simply put, all participants must have the window open before the initiator clicks the "Start [Activity]" button (that activates the activity) for SharePlay to associate them. It appears you are opening the recipient window after the session is received, but before the session is joined. Note: received is distinct from joined. The documentation for SceneAssociationBehavior mentions the scene modifier handlesExternalEvents(matching:), which is supposed to be for the app intercepting a group activity and opening the scene if it is currently not open. Should I take the above limitation to mean that this scene modifier is not properly working in regards to group activities/SharePlay? I have tested with another vision pro user having both the main window and the volume window (the targeted SharePlay window) open and the share menu did not update to show that it was sharing. So the work around essentially revolves around simply having a singular window group, but selectively showing/hiding content based on whether or not we have a GroupSession. Am I misunderstanding that the assumption here is that multiple window groups being defined (even if they are all volumetric windows as per the second limitation where the initial window style needs to match the SharePlay target window) currently does not work with SharePlay properly then? Ideally I would want to retain the multiple windows for display purposes, but will go ahead for now and see if the proposed work-around can somehow fit my use case. Again, I appreciate the detail!