I have an app that does an intensive loading of startup information from a network call to SwiftData, and the first time I start the app in iOS 17.5 (the exact same code) it makes the UI slow down and stop responding at times, although as the data is loading it appears. Slow, but it appears. But that same code in iOS 18 beta 5 loads perfectly and quickly (verified) but the UI doesn't update unless I force it. Like everyone notice on that post. I say this because the behavior in iOS 17.5 was wrong since if it is supposed to be a background thread it should not affect the UI and yet it did. It seemed like in iOS 17 the @MainActor was forced in the context of the ModelActor and even if you did the insertion operations in the background they were actually done in the MainActor and affected the UI as if you did it from a normal view. It would be great if all inserts were done in the background in the ModelActor and that when applying the .save (or maybe a new method called .saveAndNotify) the UI would be notified that it can now update that the data is already there). Like the suggested subscription to the NotificationCenter but automatic. Thanks a lot in advance.

Xcode 15.1 beta with iOS 17 beta 2, and still not working. Is there any deadline to fix this bug, is it feasible, would it arrive with iOS 17.1 and all other systems? I promise that if I could I would give you a hand. Thank you very much and best regards

Subject: Critical Issue with SwiftData in Xcode 15 Dear Apple Developer Support, I hope this message finds you well. I am writing to address a significant concern with the SwiftData framework introduced at WWDC 2023. Background: In June, during WWDC 2023, Apple unveiled SwiftData, a construct built upon the new Swift macros. This construct overlays a new API on top of Objective-C's Core Data, aiming to simplify and make data persistence more intuitive. The primary focus of SwiftData, as demonstrated in the WWDC code samples and videos, is to support apps that start from a data-empty state (akin to the Notes app) and gradually populate data, potentially integrating with a CloudKit-based backend. When integrated in this manner, predominantly through SwiftUI without background processes, the experience is seamless and indeed a significant improvement. However, there's a limitation: real-time access to the Predicate of a @Query is missing, requiring the query to be recreated. The Issue: The challenge arises when attempting to utilize SwiftData for background operations, especially with concurrent threads. SwiftData provides developers with only the mainContext, which is explicitly tied to the @MainActor, restricting its use to the main thread. This becomes problematic when interfacing with a custom API, where data needs to be frequently sent or received from a server. To create background contexts, developers are forced to resort to the ModelActor protocol, which mandates the use of Actors, contexts, and executors to manage these contexts. Ideally, SwiftData should offer an out-of-the-box background context, rather than requiring developers to set it up manually. Up until beta 6, using the background context to, for instance, send or fetch data from a server, especially during batch loads of over 1,000 records (essential for app initialization), worked flawlessly. However, once the background data load completed, the UI wouldn't refresh automatically, necessitating a restart. From beta 7 onwards, while the data does refresh, the background context ceased to function correctly. Even when encapsulated within a Task and ensuring operations are in the background, accessing the database context occurs on the main thread. This behavior stalls the UI during batch loads and results in a choppy UI experience during data send/receive operations with custom APIs. From my analysis, it seems that to address the UI refresh issue, some processes were elevated to the main thread. However, this change severely compromises the efficiency of background operations. Conclusion: We are now working with the final version of Xcode 15, and such a critical issue in a library as pivotal as SwiftData is concerning. I kindly urge the team to address this matter promptly. Thank you for your attention to this matter. Warm regards, Julio César Fernández

Xcode 15 beta 7 and there's no fix for this. @Observable can conform to Identifiable protocol, but not with Equatable (and Hashable). Because of this I cannot use .navigationDestination API, but perhaps more important than that: if I want to inject into a master/detail instance of a data from my app, I have to do it as a let and load in an .onAppear its values on other @State that allow me to edit its values. If @Observable conformed to Hashable I could pass the instance of the selected data without problem and use a @Bindable to edit it directly on the instance itself. That would be perfect. Thanks in advance, Apple staff

You forgot to put the main relationship: @Model class Row { @Relationship(.cascade) var section: Section? init(section: Section? = nil) { self.section = section } init() { self.section = nil } } Best regards

You must to include at least one resource to the target on Package.swift. Some like this: .target(     name: "MyTestLibrary",     dependencies: [],     resources: [.process("Resources/EmpleadosData.json")] ) In my example, I have a resource in a "Resources" folder inside "Sources/MyTestLibrary". Once you put this resource on the Package on Build, Bundle.module appears like magic ;) Best regards,