SwiftData Issues in macOS 14 and iOS 17
Ugh, inverse SwiftData relationship updates do not seem to trigger Observation, that feels like a biggie 😳
[…]
This feels really bad, because the relationships are the thing which make an ORM worthwhile. I.e. you’d usually have a network of many objects being displayed in distinct views (not just the simple demo). Those will lack updates as connections change.
[…]
As far as I can tell CoreData does the right thing here and updates the inverse properly.
SwiftData’s ModelContext.didSave and ModelContext.willSave don’t actually work in any current OS release, do they? FB13509149
Trying to build a SwiftData predicate with even the slightest bit of complexity is a nightmare. I only have 4 properties to filter on and the compiler completely chokes when building the macro.
Has anyone had much luck with non-optional one-to-many relationships in SwiftData?
[…]
I have the setup working, but I need to decode and insert the User entities prior to decoding and inserting the Place entities (and save!) so that I can lookup an existing User entity each time I decode and insert a new set of Places.
It seems like more effort than the rest of the framework would suggest is necessary.
Yeah, it’s non-intuitive - you have to do it what I think of as “the wrong way around.”
Decode and initialise your User, but don’t insert it yet!
Decode and initialise your Place(s), and use the just-initialised User as the user for those Places
Then insert the Place(s).
What I found is SwiftData is really finicky about relationships. The only reliable way is to make all of them optional, then first insert the base model and only the add the related models to it (preferably inserting them first too).
A SwiftData
PersistentModelclass stores the actual property data in an opaqueBackingDatathing which is created with the model. The interesting thing is that this seems to require aModelContainerexisting “somewhere” that has the model registered already.[…]
Using the same type in multiple containers may be an antipattern. Though it shouldn’t be, they are global types.
I’m already running into crashes seemingly related to this in my test suite.
I encountered this just a couple of days ago, and it makes me vaguely concerned that something’s going to end up inadvertently tied to the WRONG container stack, just because of the order in which things were initialized.
It is the bug where SwiftData doesn’t refresh the object when the underlying object changes. I think I can hack-fix that ;-)
Apple needs to start internalizing the idea that APIs need actual internal app customers before they can be ready for third-party developers. Looking at you, SwiftData.
With WWDC 2024 approaching, this article will evaluate the overall performance of SwiftData since its initial release during the Xcode 15 period (i.e., its first major version), and provide a forecast of its future development.
[…]
Although SwiftData’s design is highly visionary, its launch was clearly rushed, and its first version not only lacks some important features, but several key issues have also severely impacted its performance and usability[…]
[…]
SwiftData’s current performance in converting predicates that include optional values (transforming predicates into SQL commands) is poor, especially when handling “to-many” relationships with optional predicates. This deficiency not only severely impacts SwiftData’s usability but also significantly restricts the functionalities that applications using SwiftData can offer.
[…]
Appendix: Some Key Features Missing, Major Issues, and Partial Temporary Solutions in the First Version of SwiftData
Previously:
