It is a requirement that when you use CloudKit, your schemas are always backwards compatible for this exact reason. Your schema on CloudKit might be V2 but your user hasn't updated yet so their device is still on V1. Or, like in your example, you have 2 devices syncing but one is V1 and the other is V2.

Adding my experience using Xcode 15.4. Started getting these errors every other build after I added a Build Tool Plug-in from a Swift Package (SwiftLint to be specific). Soon as I removed it, the errors are gone.

@Bardi In my case I've already inserted both models into the context. The crash reference in that thread is a well known one to me already.

If instead I change the type to Data, it works fine. But then I need to manage another type that stores the raw data and manually decode and encode. This is a nightmare. Why does Apple release documentation that is completely non-functional for a very common use case?

If your migration plan includes a custom migration, this solution no longer works in iOS 17.4 and will crash (not in the catch, but in the ModelContainer init). I submitted feedback on this issue: FB13694972. It's easily reproducible. The first attempt to initialize the ModelContainer will fail normally and throw an error, as expected. The second one just crashes and complains about the model not being compatible with CloudKit, even though it's set to .none. Before iOS 17.4 works fine.

Is this an issue again? I previously ran into issues with migrating my schema to be CloudKit compatible and posted about it 2 months ago here: https://forums.developer.apple.com/forums/thread/744491. My solution I found was to disable CloudKit via the ModelConfiguration with CloudKitDatabase.none if it initially failed to load the ModelContainer. It allowed my data to go through the migration process first before attempting to sync with CloudKit. Everything was working fine, until just this week. I had a couple more crash reports show up. I reproduced it locally and sure enough, even with the CloudKitDatabase set to .none, it's crashing with an error CloudKit integration requires that all attributes be optional, or have a default value set.. It's not even throwing an error for me to catch, it's just crashing with Fatal error: 'try!' expression unexpectedly raised an error: SwiftData.SwiftDataError(_error: SwiftData.SwiftDataError._Error.loadIssueModelContainer) (my code doesn't use try! or any fatalError(), I only catch the error and attempt to gracefully fail with a user facing error message). It seems like iOS 17.4 might have broke this again? Can anyone else confirm?

I figured out the solution, in case anyone else stumbles on this and is looking for an answer. It seems that the solution is to do: do { if let container = try? ModelContainer( for: Foo.self, Bar.self, migrationPlan: SchemaMigration.self, configurations: ModelConfiguration(cloudKitDatabase: .automatic) ) { self.container = container } else { self.container = try ModelContainer( for: Foo.self, Bar.self, migrationPlan: SchemaMigration.self, configurations: ModelConfiguration(cloudKitDatabase: .none) } } catch { // handle error } Essentially, if it fails the first time, disable CloudKit. This lets the SchemaMigration perform and complete and will load the container. Of course, CloudKit is disabled still, but the next time the app launches, the schema will be compatible and CloudKit will load up fine.

I'm currently dealing with the exact same thing. Using Github as my SCM, I was getting errors telling me I had to reconnect, but clicking reconnect only gave me another error saying it was incomplete. Thought maybe I'd just start over from scratch and deleted all Xcode Cloud data. Now it gets stuck at "Grant Access to Your Repository" and I get a popup error telling me my app couldn't be added to Xcode Cloud. Added my own feedback. FB number is FB9785098.

I've also been encountering this. Google lead me here. No other answers anywhere. Any luck resolving this?