I have a similar issue when updating model attributes in an .onChange event (FB13812446, filed in May this year). Pretty sure that it happens within an .onChange is not relevant. Just checked with the sample project I attached to this FB: Still causes the memory to rise using the latest Xcode beta (Version 16.0 beta 6 (16A5230g)).

I filed a feedback for that a few weeks ago and it seems to be fixed in the latest iOS 18 beta at least. It still does not work in the simulator of the latest Xcode beta, though. So be aware, that you only get the intended behaviour on device. (Not sure about the situation on iOS 17, though)

Hi! You could setup the ModelContainer manually (to know when the SwiftData stack is being initialised and probably also to have the possibility to decide what the files are named and where they are stored) and backup/copy those files beforehand. By manually setting up the stack I mean something like that: let dbRootURL = (URL.documentsDirectory) let dbURL = dbRootURL.appendingPathComponent("TheDB.db") // open the db let fullSchema = Schema(ModelV3.models) let dbCfg = ModelConfiguration(schema: fullSchema, url: dbURL) return try ModelContainer(for: fullSchema, migrationPlan: DBMigrationPlan.self, configurations: dbCfg) Those are pretty much the standard files. Other than that "default.store" has usually renaming the "sqlite" extension. Maybe that confuses the tools you are using. Try renaming it to .sqlite and see if it helps. Cheers, Michael

My guess is, that Xcode and the iOS beta are out of sync. We need to wait for the next Xcode beta to have it working again. (Ran into the same issue after upgrading to iOS 17 Beta 6 - Beta 5 was fine)

I think this relates to this issue mentioned in the release notes of Xcode Beta 6: @Model classes with initial values for stored properties result in an error that self._$backingData is used before being initialized. (113572344) Workaround: Assign initial values to stored properties in the body of an initializer. For example, instead of this code: [...]

Currently it only seems to work, if the model1 relationship in Model2 is optional and only set after the insert: [...] let m2 = Model2() db.insert(m2) m2.model1 = m1 [...] db.save() See also here and here. I filed FB12363892 for that back in beta 1, but no reaction so far.

I think you are running into the sam issues I have over here. The gist of it is, that currently to-one relationships can only be populated after the entity is initially inserted into the context. Which also means they must be optional, which is unfortunate from a modelling perspective. I filed FB12363892 for that.

I saw that saving relationship currently does not seem to work, if there is no inverse relationship being defined. See here

I ran into basically the same problem. Below is the smallest sample app I came up with demonstrating this issue. It does not happen the first time you navigate in the stack, but on all subsequent times. I filed FB10662166 - feel free to reference in you feedbacks ;-) import SwiftUI struct SidebarEntry: Identifiable, Hashable { let id = UUID() var localizedName: String } let sidebarEntries = [ SidebarEntry(localizedName: "Files"), SidebarEntry(localizedName: "Bookmarks"), ] // MARK: - main - @main struct NewNavigationTestApp: App { @State private var sidebarSelection: SidebarEntry? var body: some Scene { WindowGroup { NavigationSplitView { List(sidebarEntries, selection: $sidebarSelection) { entry in NavigationLink("\(entry.localizedName)", value: entry) } } detail: { ZStack { // workaround if let sidebarSelection { if sidebarSelection.localizedName == "Files" { TestStackView() } else if sidebarSelection.localizedName == "Bookmarks" { Text("Bookmarks View") } else { Text("Unknown View") } } else { Text("No selection") } } } } } } // MARK: - FilesView - struct TestStackView: View { var body: some View { NavigationStack { List(0 ..< 999) { idx in NavigationLink("\(idx)", value: idx) } } .navigationTitle("Numbers") .navigationDestination(for: Int.self) { idx in Text("Hello") } } }

Unfortunately @MobileTen's suggestion with the @Binding does not work in my case, since I need to modify _internalNumber from within TestView as well. This was not mentioned in my problem description above. The problem case here really is to have an internal @State initialized from an external value and being able to change that "State". Once the "outside" number changes (in ContentView, I would expect TestView.init to be called again (which actually happens), TestView.body to be called again (which also happens) and the changed number to be displayed (which does not happen ;-))

Seems like nobody is using SwiftUI on macOS :-( So far I tried it on three different machines (all running the lates macOS/Xcode). One even installed from scratch, to be sure it's nothing in my installation. So my guess is, that it's just broken. I filed FB10011754 for this. Anyway if somebody has @SceneStorage working on macOS I would like to hear from you and maybe figure out what's different that makes it work.

The simplest function which returns Void as in your example () -> Void would be {}, which is a function doing nothing and returning nothing.

Ok, I found the issue (in case anyone with similar issues stumbles across this thread): If you use Set as the type of the relationship property in the NSManagedObject derived class, the above described behavior occurs. Stick with the good old NSSet and it works as expected.

It only does not work, if the data is stored on iCloud Drive. If it is copied over locally on the iPad it works. So the real question is: How do I make it work on iCloud Drive as well...

At least it's good not to be alone ;-). Filed as FB9487340. The simplest example I found, was just having a TextField and tapping on it after a reset of the simulator. Once the keyboard appears and shows the "swipe to type" instructions the crash occurs. The reset of the simulator is necessary so that the "swipe to type" instructions appear, which seem to be the causing the crash in that case.