How to configure a custom ModelContainer using ModelConfiguration
How to configure a custom ModelContainer using ModelConfiguration 관련
Updated for Xcode 16
When you use modelContainer(for:)
you get a default configuration, which means SwiftData decides where your database is stored, enables autosave, disables undo, and more. You can override some of these by using overloads of the modelContainer()
modifier, but for complete control you need to create a ModelConfiguration
instance by hand, then use that to create your container.
For example, if you wanted to write to an exact file in your documents directory rather than the default location, you would use code like this:
@main
struct RecipeBookApp: App {
var container: ModelContainer
init() {
do {
let storeURL = URL.documentsDirectory.appending(path: "database.sqlite")
let config = ModelConfiguration(url: storeURL)
container = try ModelContainer(for: Recipe.self, configurations: config)
} catch {
fatalError("Failed to configure SwiftData container.")
}
}
var body: some Scene {
WindowGroup {
ContentView()
}
.modelContainer(container)
}
}
One big advantage to creating your configuration by hand is that it allows us to disable saving entirely – if you have particularly sensitive data, or perhaps you’ve shipped some template data that shouldn’t be changed under any circumstances.
You can disable saving like this:
let config = ModelConfiguration(allowsSave: false)
The ModelConfiguration
initializers expose most of the options you can use with ModelContext
, including schema, CloudKit containers, and more. For example, you could create a configuration that loads specific model types, writes to a custom database file, and connects to a particular CloudKit database name, like this:
let storeURL = URL.documentsDirectory.appending(path: "database.sqlite")
let schema = Schema([Recipe.self, User.self])
let config = ModelConfiguration(schema: schema, url: storeURL, cloudKitDatabase: .private("pastalavista"))
container = try ModelContainer(for: schema, configurations: config)
The power of this approach is that you can use multiple ModelConfiguration
objects to configure a single model container – perhaps you want recipe data to be stored in one file and user data to be stored in another, or perhaps one should back up to CloudKit whereas the other shouldn’t.
Important
Irrespective of which set of configurations you use, you must still make sure you send the full list of model types to your ModelContainer
initializer, either explicitly by listing them all or implicitly through relationships.