For some reason this bug is solved in Xcode 13.2.1 for the Simulator, but not for an actual device.

Found this passage in Apples Core Data Documentation: https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CoreData/FaultingandUniquing.html When a fault is fired, Core Data does not go back to the store if the data is available in its cache. With a cache hit, converting a fault into a realized managed object is very fast—it is basically the same as normal instantiation of a managed object. If the data is not available in the cache, Core Data automatically executes a fetch for the fault object; this results in a round trip to the persistent store to fetch the data, and again the data is cached in memory. For my understanding it basically says that doing a fetchrequest manually and accessing the fault data is not a big difference when the concerning data wasn't available in cache yet.

I just found the issue on my side. During further investigation I realized that these messages came together with other messages referring to one specific entity. I preload Core Data from a json file with some data which eventually change from time. For development purposes each time the app launches,I update my preloaded data from the json file It turned out that I created new objects during that update to run a comparison and forgot to delete the unnecessary objects right after. Since that update process creates several hundred objects, that adds up quite fast. They were now floating around in core data without any purpose. And CloudKit had to sync them. However, at the end it's still quite small string data and why this causes into those cryptic debug messages and hours of syncing, is still a mystery for me.