These are the logs when migration happens from NSMigrationManager

How can I confirm this behavior when migrating using NSMigrationManager? I don't think you need to explicitly checkpoint the store. The Core Data migration process should handle that for you – If it doesn't, I'd see that a framework bug When I enable com.apple.CoreData.MigrationDebug the lightweight migration logs the WAL checkpointing, however, when using NSMigrationManager no such log appears. When I tried inserting 1000 objects, all of them get inserted into the sqlite file. Nothing gets inserted in WAL file. Is the behavior different for NSPersistentCloudKitContainer? Regarding the error, did you try to set up options in the following way: Yes, this works. However, if the NSMigrationManager handles this then should be avoided, right?

Is it necessary to manually checkpoint the WAL journal before starting the migration or does the NSMigrationManager handles it internally? Ref: https://developer.apple.com/library/archive/qa/qa1809/_index.html

Thank you for sharing the code snippet. Can you please update the code that demonstrates initialization of following variables for the sake of completeness of the code sourceModel destinationModel sourceStoreURL destinationStoreURL Also, if you could show how to replace the newly created destinationStore with sourceStore. Are there any edge cases that are to be handled? Should I manually delete the wal and shm files? guard let fileURL = Bundle.main.url(forResource: "Model", withExtension: "xcmappingmodel") For the snippet above, should I use xcmappingmodel or cdm extension? After compiling, a cdm file is created from a MappingModel

This is a bug in Xcode as confirmed by Apple. The only workaround at the moment is to manually load the mapping and update the hash as mentioned by @ulizurucker Ref: https://developer.apple.com/forums/thread/774218

Thank you for your response. The workaround you mentioned may work, however, the step #3 of calling the migrateStore function is extremely complicated. The documents also does not explain much. Some of the points that I can think of is Should the migration be called on the background context. Where should be the new temporary destination file be created? Are there any other functions that I should invoke before and after migration? Should I explicitly delete the temporary file if migration fails. It would be great if you can share a resource with code sample that explains how to use the migrateStore method.

You can print the path of your app to the Debug Console print(Bundle.main.bundlePath)

Found a similar issue on forums https://developer.apple.com/forums/thread/120013

Also, I just checked Staged Migrations. It supports macOS 14 and onwards.

and a space isn't allowed in a class name. The space is in the App name not in the class name. Thanks for the additional information about staged migrations. Will check them out.

Swift does not support macros, so you can’t use that technique in Swift code. Is it possible now since macro was introduced in Swift 5.9

Thank you for answering in detail. I have following questions Are you suggesting that iCloud-sync should be enabled by default and if the users want to turn it off then they can do that from System Settings app? Based on your answer, I think I agree that having toggle to enable/disable iCloud will not provide consistent experience. But then I don't understand how that can be fixed since iCloud is available only to the premium users in the app. The toggle is off and disabled for the free users of the app. Is there a way to know if the user has disabled iCloud for the app from System Settings? c. A new user launches the app and add more data. I am sorry, I did not follow this part where data of 2 users get mixed. Won't the new user have a separate container where their data will be separately stored and if they have logged into their iCloud account then it will sync in their account?

Thanks a lot for this answer. Was stuck on this for more than 2 days.

From past few days, my Xcode has been crashing every 5 mins

Hi. I am facing the same issue and have filed a radar. Is there a temporary workaround until the issue is fixed in the backend?