Document-based SwiftData apps fail to identify a store on iPad?

Also submitted as FB13950404

I'm seeing the same issue in Xcode 16 bets 2 with a document based app on iOS 18.

This continues to be an issue on iOS/iPad OS Beta 4

This remains an issue in the latest betas. Are document-based SwiftData apps not supported in iOS 18? This capability was just introduced last year ☹️

I tried the sample app with Xcode 16.0 beta 6 (16A5230g) + iPadOS 18.0 (22A5350a), the latest public betas we currently have, and didn't see the issue happening. So it seems that the issue has been fixed. Would you mind to give it a try and share what you see on your side?

Best,
——
Ziqiao Chen.
 Worldwide Developer Relations.

"Sorry, but the same issue persist on XCode Version 16.0 (16A242d), which is already public version."

I just updated my iPhone to iOS 18 and confirmed that the sample app does not present any issue on my iPhone. Did you try to run the sample app on a physical device?

When I run the sample on an iOS 18 simulator, I did see an error saying no location available to save “Untitled.sampledeck” though. If the issue you saw was that, I'd suggest that you file a feedback report.

Best,
——
Ziqiao Chen
 Worldwide Developer Relations.

I am also able to easily reproduce this issue on an iPad running an unmodified version of the sample project, using the current release version of Xcode and iPadOS. It did not happen with the first document I created, but re-opening that document reveals that nothing saved. The second document did save changes, but it resulted in this error on close.

This isn't the first time that document-based apps backed by SwiftData have been completely broken in an update.

Has anyone shipped a document-based app using SwiftData? I am wondering what the viability of this technology is, since my team is close to releasing a brand new app that relies on it. At this point I am terrified that it will keep breaking.

These aren't edge cases either. I am testing with Apple's (FlashCard) sample project to eliminate the possibility that my code is involved.

It seems to me that if anyone had tested the integrity of documents created by SwiftData (by closing and re-opening them), both this and the prior issue would have been found right away.

The example app from this link is also not working on my iPad: https://developer.apple.com/documentation/swiftui/building-a-document-based-app-using-swiftdata

I was a big fan, but I’ve decided to move away from SwiftData. Instead, I’ll switch my data model from @Model to @Observable and Codable, and figure out a way to store it as JSON.

I have the same issue, it has completely broken my project. I have upgraded to Swift 6, but that didnt help. I have tried manually creating a container, but the container is not unique to the document.

I have a large data model with many relationships, it stores simple data and image data. It has been working great for a year, and then completely crashes on IOS18!

I am at a loss, please help!

Confirmed this is still a problem in the simulators with the shipping XCode16. It's nothing to do with SwiftData - it's any Document app including creating one from the standard app templates as per my Stack Overflow question.

The problem is related to using iOS18 in the simulator - an earlier OS in a new simulator created from XCode16 has no problems.

It stops anyone from testing FileDOcument apps on iOS18 simulators, which is a pretty serious brake on development.

Thread 1: Fatal error: Failed to identify a store that can hold instances of SwiftData._KKMDBackingData<SwiftDataFlashCardSample.Card> from [:] ... It did not happen with the first document I created, but re-opening that document reveals that nothing saved. The second document did save changes, but it resulted in this error on close.

I'd like to confirm that the relevant engineering team can now reproduce the issue described above, thanks to @litkyle, and is actively working on it. The issue is tracked with FB13950404 (or r.130044320 internally).

For the "no location available to save 'Untitled.sampledeck'" error, I saw it when running the app in a simulator, but not on a device, as I mentioned above. This issue may be relevant to FB13950404, but I am not completely sure if it is exactly the same, and so would suggest that you file a new feedback report so it doesn't get missed – If you do so, please share your report ID here.

Best,
——
Ziqiao Chen
 Worldwide Developer Relations.

As requested, added a separate FB15343012 for just the document-based app case, including attached sample from a brand new project.

I got a response to my feedback saying first "This crash arises from a document that has been closed with unsaved changes. In order to avoid this crash, ensure that the ModelContext is saved before closing the document." then "Thank you for filing the feedback report. We have deployed the fix. Please verify this issue with iOS 18.1 Beta 6".

Unfortunately it looks like the crashing part was fixed, but not the saving of the document. I think they are both equally important, since a document-based app is worthless if you cannot save your work.

This issue can still be seen using the unmodified FlashCards sample app.

Can we get some guidance on this as to whether or not it is now our responsibility to manually save changes? Prior to iOS18 this was not required, and likewise the sample project does not have any code to manually save.

This was tested with Beta 6 and Beta 7, using Xcode Version 16.1 beta 3 (16B5029d)

I'd also like guidance on this issue. Autosave clearly doesn't work in Apple's official FlashCards sample app.

To echo what others are asking: In a SwiftData document-based app, are we now responsible for saving if we target iOS 18? Or is this a bug that's on the team's radar?

Traditionally, UI/NSDocument-based architecture handles autosave pretty well, and I don't think DocumentGroup + SwiftData should be an exception in this regard.

As of today though, it seems that there is a bug related to SwiftData autosave, as discussed in the Xcode 16 MacOS Sequoia SwiftData not saving data after running application post.

Though you can probably work around the issue by explicitly saving the model context after making a change, I’d suggest that you file a feedback report against that autosave doesn't work in DocumentGroup + SwiftData – If you do so, please share your report ID here for folks to track.

Best,
——
Ziqiao Chen
 Worldwide Developer Relations.

I had this error too. Turned out that I was missing one of my models in my ModelConfiguration's schema. Once I added the missing model to the schema, error went away.

let schema = Schema([Person.self, Car.self, City.self])
        let modelConfiguration = ModelConfiguration(schema: schema, isStoredInMemoryOnly: false)

This is my first post on the Developers Forum, so please excuse any procedural errors on my part.

I just ran into the "Failed to identify a store that can hold instances of" fatal error. (XCode Version 16.1 beta 2 (16B5014f), MacOS 15.4.1 (24E263))

In my case, (without presenting all of my code,) my code ran before I added a CGSize property to the class on which I'd applied @Model within my document-based MacOS application. Then after adding the code and during what appeared to be the first autosave, my application generated the fatal error already mentioned within UsesSwiftData2App.

This is not a solution, just a piece of information which may or may not help while debugging this problem.

To whom it may concern, I jumped the gun in my previous post, and would ask you not to accept it as it is.

I tried to add an other non-CGSize property to my struct with @Model applied, and I got the same error.

It appears that adding one more property to my struct, of any type, may be triggering the error.

Bottom line, if I find the time, I will try to form a minimal pared down version of my application, in which I can show you a single line of code change which triggers the error.

Until I do so, I do not think my post would be useful to this group.