Hi, I could probably wait until tomorrow's deep dive session and just find out, but I'm curious to ask, are the SwiftData persistent containers still backed on SQLite primarily? I'm excited to replace Core Data in my existing SwiftUI app, but I've been dropping down to SQLite3 directly, for example, for using the FTS5 module for creating full-text-search tables alongside my Core Data tables to back more relevant results for .searchable UIs.

Where is the link to the Starter and completed projects for this session

How do I customize my app's startup experience when using DocumentGroup in SwiftUI with SwiftData? I don't want my users to be greeted with a document browser on startup. Rather, I want to offer an experience like PhotoShop where the user is greeted by an "empty" version of my app's editor view. They can then use something like File->New or File->Open to get started.

What is the best way to use swift data to store one off data models? For example an application state that you want to be persisted across application launches. The only examples I've seen use arrays of items which wouldn't work for having just one application state. Is it possible to query just one item?

Is SwiftData going to be immediately available to use with iOS 16? I ask because I'm working on an app which I'd like to release around the end of this month, and I'm about to implement CoreData for it, but wanted to see when SwiftData would be available. My guess was that SwiftData is for iOS 17 so I should just stick with CoreData for now and switch over later, but just wanted to check to make sure. Thanks!

I am watching Swiftdata videos, but so far they haven't mentioned CloudKit explicitly, and I'm not sure what is the relationship between SwiftData and Cloudkit at this time. Are these models automatically synced with Cloudkit? If that's the case, do the migration plans work for cloudkit as well?

I understand that in the demo we have version 1 to 3 in the schema plan, but where does the current version live, the one with relationship decorations? And how is the current version's migration type declared or handled?

I made the changes described in the WWDC2023-10154 tutorial that were intended to allow the user to create a new (blank) document. However, every new document contains the "Compiler"/"Grace Hopper" card that was added to the persistent store in the earlier, non-document-based part of the video. I've tried a full clean and clearing derived data but I can't seem to get that card to go away. What am I missing? How can I make sure that new documents are created without any data?

Hi, I have an app that uses Core Data + CloudKit, and which allows sharing of entities with other iCloud users. It works in a manner similar to the sample application provided on the Apple developer site. Is this use case supported with SwiftData? The ability to share data with other iCloud users is fundamental to my app, so I cannot migrate to SwiftData unless this functionality is provided.

Can SwiftData be used with UIManagedDocument? Also if the UIManagedDocument is integrated with CloudKit?

Hi, re: the SwiftData session "Create an app with SwifData" (https://developer.apple.com/videos/play/wwdc2023/10154) I noted the mention of generating sample preview data. In CoreData, I had a similar need and this was achieved by creating a shared in-memory context; fairly straight forward. The example given for SwiftData was decorated with @MainActor and then added to the target project, then in the #Preview closure, the modelContainer is amended to point to the preview data. Anyways, my problem is that I'm receiving an error when trying to render the preview in question: main actor-isolated let 'previewContainer' can not be referenced from a non-isolated context I suppose my issue is not having used the MainActor wrapper before and being unclear on what's possibly going wrong here (or if it's not just a "me" problem). Can anyone help?

With Core Data you can control the journal mode as follows: let dictionaryOptions = [NSSQLitePragmasOption : ["journal_mode" : "DELETE"]] Is there a SwiftData equivalent?

How does SwiftData work with background operations? CoreData had background context that could be used to avoid UI hang for heavy operations. Is there an equivalent in SwiftData, and if so, do I have to merge changes or does it save directly to persistent store?

Hi, does the build along require macOS Sonoma or can one simply use macOS 13.4 Ventura with Xcode 15 Beta?

Using the 'Create SwiftData Code...' action in Xcode results in Model that have bi-directional relationships between many of my entities (which is correct - my Core Data model includes this). All of these Relationships are marked as invalid, however, with the following error: Circular reference resolving attached macro 'Relationship' Most ORM's, in my experience, have a way to mark one end of a bidirectional relationship as an 'owner'. Is there something similar available in SwiftData, or is this scenario handled in a different way? Or am I going to need to remove all of my bidirectional relationships?

It seems that when you delete model objects with a relationship there seems to be a crash occurring if the collection your observing is tied to a ForEach. Below is an example of the models in SwiftData @Model class Category { @Attribute(.unique) var title: String var items: [Item]? init(title: String = "") { self.title = title } } The relationship is defined between the category and the item @Model final class Item { var title: String var timestamp: Date var isCritical: Bool var isCompleted: Bool @Relationship(.nullify, inverse: \Category.items) var category: Category? init(title: String = "", timestamp: Date = .now, isCritical: Bool = false, isCompleted: Bool = false) { self.title = title self.timestamp = timestamp self.isCritical = isCritical self.isCompleted = isCompleted } } So if I were to create a category individually so i can later tag it to an item i'm just following the standard proceedure of creating a category and inserting it into the context as you can see below Button("Add Category") { let category = Category(title: title) modelContext.insert(category) } .disabled(title.isEmpty) Then later on when i create my item I associated an existing category with an item and insert that into the context so now there is a possibility to have many items associated to a single category as you can see below @State var item = Item() // Item is bound to form elements .... Button("Create") { modelContext.insert(item) item.category = selectedCategory.title == "None" ? nil : selectedCategory dismiss() } This is where the problem occurs... If i try to delete a category now after inserting it @Query private var categories: [Category] .... ForEach(categories) { category in Text(category.title) .swipeActions(allowsFullSwipe: true) { Button(role: .destructive) { withAnimation { modelContext.delete(category) } } label: { Label("Delete", systemImage: "trash.fill") } } } The application crashes because the foreach is still being executed by the Query property wrapper as if the item still exists even though it has been deleted, but it's trying to access the title on an object that doesn't exist anymore. I've also noticed that when trying to insert duplicate items using the Atrribute macros this causes a crash too. It's almost as if the query collection just isn't being updated with the new values of a category being deleted. I've filed a feedback under FB12286699 (Crash when deleting items in relationships) in Feedback assistent hopefully this can get picked up.

As far as I can tell, there’s no equivalent to Core Data’s NSFetchedResultsController in SwiftData. It would be very helpful to have a way to respond to sets of changes in a ModelContext outside of a SwiftUI view. For instance, this is very helpful when using a Model-View-ViewModel architecture. The @Query property wrapper is great for use in a SwiftUI view, but sometimes it’s helpful to process data outside of the view itself. The fetch() method on ModelContext is helpful for one-time operations, but as far as I can't tell it doesn't address receiving changes on an ongoing basis. Am I missing some equivalent for this use case? Also filed as feedback FB12288916

If I make model changes in the mainContext using a batch operation like context.update OR on a background thread ModelContext ModelContext(container), my saved changes are not automatically reflected in the UI (a List of models). Also ModelContext.willSave and ModelContext.didSave don't seem to get called. Will automatic UI updates work in an upcoming Beta but are NOT in Beta 1? Or will we refresh View/@Query based on a ModelContext.didSavenotification? Or should this be working in Beta 1 and I am missing how it works?