@RyanTCB , did you ever figure this out?

Nonisolated Extension Functions I liked @eoonline's solution. This is a variation of his solution for the data(for:) and data(from:) functions: extension URLSession { public nonisolated func getData(for request: URLRequest) async throws -> (Data, URLResponse) { try await data(for: request) } public nonisolated func getData(for url: URL) async throws -> (Data, URLResponse) { try await data(from: url) } } What is nonisolated? This means the function can be called OUTSIDE the actor's isolated domain. Is it safe? Yes, nonisolated methods should typically be ‘read-only’ and not modify any state. In this case, since the getData functions are just performing a network request and not modifying any state, it’s safe to make them nonisolated.

I have observed the same thing. In a view where I insert a new data, I have: @Environment(\.modelContext) private var modelContext ... .onAppear { modelContext.autosaveEnabled = false } Yet when I terminate the app and re-open it, I notice the data did indeed get into persistent storage. Update After more testing I discovered the root of the problem: Setting autosaveEnabled on the modelContext does not persist from one screen to the next. For example: Say when ParentView loads you turn off autosaveEnabled in the onAppear (like the code above). Then navigate to DetailView. Observe that autosaveEnabled is set back to true now on DetailView. I would have thought it would have persisted after I changed it but it did not persist.

Error This is a constraint error. It means you added a constraint for the id attribute on your List entity. So when you try to save, Core Data sees there is a duplicate id and so will throw an NSConstraintConflict error. Your error message could be: "That id already exists." or "Duplicate id found." Another way to handle this is to set the mergePolicy property on your context property: context.mergePolicy = NSMergePolicy.mergeByPropertyObjectTrump // Keeps the new entity or context.mergePolicy = NSMergePolicy.mergeByPropertyStoreTrump // Keeps the existing entity You can set that mergePolicy using onAppear for just this view or set it when you first create your persistent container. Hope this helps future Core Data coders!

This is a constraint error. I'll submit an answer so it's clear what it is and possibly how to fix it.

Hi Ryan, I know it's been quite a while with no answer but I'll answer for future readers! What purpose does the inMemory Bool serve? It simply allows you to set your persistent store to a temporary location that gets wiped out after it's used so your persistent store is not persistent. You see, normally the store of data will persist on the drive (hardware) of a device. If you run your app and expand your persistentContainer in Xcode's Variables View, such as: _storeDescriptions > [0] > _url, you'll see this long path where the persistent store is actually located. But when inMemory is set to true, the _url value is just file:///dev/null When else would you set it to true? Only when you're testing and you want to create/save/update/delete data and not have it persist once the app stops running. So definitely don't set to true when releasing to the App Store. 😃 When would you set it to false? When you deploy your app to TestFlight or to the App Store or when you want to do further testing that requires your data to persist after your app shuts down. When it is set to true it then creates the persistent store description to a file URL with path "/dev/null" -- what does this mean? This is a special place that does NOT persist and will vanish once your app stops running. The full URL is: file:///dev/null This is kind of a "secret place". It's so secret that you can't find it on your hard drive, even when you show hidden files. The only way I can see this location is by taking that URL and putting it in Chrome (Safar won't show it). Do we need to set the Persistent Store Description to something else in production code? Nope. Your app will know where to put it. Hope this helps!