It does work on my M4 iPad Pro with iPadOS 26, so that's better than nothing

Was just dealing with the same thing, and removing the id: \.self from a ForEach I just added seems to have solved it - thanks! As to the reason, my guess is that SwiftUI is holding a Dictionary of every object, using the id: value as the key - SwiftData is likely mutating these objects behind the scenes, to reload data, fault data, etc. That would cause this error to happen. Omitting the id: parameter in the ForEach, or using id: \.id would use the stable identifier as the key of the 'hidden' Dictionary, therefore eliminating the issue. All of that makes sense to me, at least - unfortunately, we use id: \.self so frequently, that I can almost guarantee that I'll make this mistake again in the future. Would be nice if making this error were impossible, or if Xcode had a way to warn us about it.

I have some information that may be helpful to others, and to those addressing the Feedback created. I have the same issue in a brand new app, created yesterday with Xcode 16 (16A242d). Deleting Derived Data and Erasing my simulator did not help. The issue started when I added a new relationship to one of my Model classes - I've been able to 'fix' the crash (not entirely proven yet, but the initial crash is no longer happening) by moving the initialization of the relationship from the field definition to the constructor. In other words, this code crashes on launch: @Relationship(deleteRule: .cascade) var selections = Selection() While this code does not: @Relationship(deleteRule: .cascade) var selections: Selection init() { selections = Selection() } I have filed a feedback for this issue as well, and referenced this thread: FB15250668

It's my understanding that only SFSymbols are supported for Control Widget icons - I have no documentation for that, but have seen a lot of chatter on socials

Quick update - the CloudKit dashboard problem remains, however my data is sync'ing again. I found an error in my app logs after posting this that indicated sync'ing was halted because of a new field on one of my entities (this is the production environment). I had deployed my schema changes about 4 hours prior, and the Record Types in the CloudKit dashboard all looked correct, but apparently it took several hours for the schema update to 'take'? 😳 At any rate, I still can't use the CloudKit dashboard to query any of my data in any Private database for any of my Apps. Just filed a Feedback - FB14824265, if anyone is listening 🙏

Hey, it worked - FinanceKit is now available in Feedback Assistant 🎉 Thanks!

Same error here

On a whim, I tested with both Universal Links, and the older URL Scheme links (<your-app-name>://some-deep-link), and neither of them are working

Filing a Feedback on Feedback Assistant is exactly what I did! 😂 FB13867472 (FinanceKit: FinanceKit should be an option in Feedback Assistant!)

@jonduenas is on the right track here. I started seeing this error today, and yesterday I updated my SwiftLint configuration to use the Build Tool Plug-in mechanism, rather than the Build Phase mechanism. This is almost certainly the cause of the issue (at least for me). Whether it's a problem with SwiftLint (currently using 0.55.1) or with Xcode, I can't say. This is with Xcode 15.4, however I've been using the version without this error since it was released.

Still here on the RC - what gives?

Fast Forward one year using Xcode 15 - I got this same error, but the 'Register device' button is gone for me. On the plus side, all I had to do was to open the Signing and Capabilities tab on my app target, and it automatically started the device registration 👍 Seems like this is something that the build could handle, or the error could at least prompt us with the solution.

Ok, after reviewing the 'Trips' sample application that accompanied the 'Dive deeper into SwiftData' video from WWDC '23, I see that this is handled between the Trip and both the BucketListItem and LivingAccommodation entities by simply omitting the @Relationship annotation on the 'child' entities. I have a few questions, based on what I see: If a LivingAccommodation entity is loaded via a @Query, will the trips field be populated by the SwiftData system? On both child entities, the trip field is an Optional Trip - is this required in this scenario? I would imagine that it doesn't make sense to have a LivingAccommodation object without an associated Trip object, and my own Model is similar

I have a similar issue that I identified as being related to the Form. In my case, I had an onSubmit attached to the Form, which basically does the same thing as yours. If I change the Form to a VStack, everything works great, although it loses all of the Form styling, of course. I've filed a feedback for this: FB9136142