Migrating an existing SwiftData store (explicit SQLite URL) to an App Group with CloudKit after migrating from Core Data

Question

Created 3d

Replies 0

Boosts 0

Participants 1

I have a production app that originally used Core Data + CloudKit and was later migrated to SwiftData.

The SwiftData migration preserved the existing SQLite store by explicitly pointing ModelConfiguration at the original database:

let configuration = ModelConfiguration(url: storeURL)
let container = try ModelContainer(for: schema, configurations: configuration)

Because of this, my app does not use the higher-level ModelConfiguration(groupContainer:cloudKitDatabase:) initializer.

I would now like to migrate the store into an App Group so it can be shared with widgets.

During the WWDC26 SwiftData Group Lab (around 18:53), the guidance was:

Moving to an App Group container is more involved: it's a different directory and entitlements can't be aligned to the old location, so you'll get a new container and must copy the existing data over into the group container, then start from there.

However, I couldn't find documentation describing how Apple recommends performing that copy for a SwiftData application that already uses an explicit SQLite URL.

Why the Core Data APIs don't seem applicable

The obvious approach would be to use Core Data APIs such as:

replacePersistentStore
migratePersistentStore

However, these APIs require a Core Data stack and a managed object model (.momd).

After migrating completely to SwiftData, I no longer have a .momd in my project, so creating an NSPersistentContainer solely to move an existing SQLite store doesn't appear to be possible.

Is there a supported way to use these APIs with a SwiftData store, or are they no longer intended for this scenario?

Experiment

Since the migration happens before creating the ModelContainer, I experimented with simply moving the entire persistence package using FileManager before SwiftData is initialized.

Specifically I move:

Store.sqlite
Store.sqlite-wal
Store.sqlite-shm
.Store_SUPPORT
Store_ckAssets

from the application's Application Support directory into the App Group container, and then initialize SwiftData using:

let configuration = ModelConfiguration(url: appGroupStoreURL)
let container = try ModelContainer(for: schema, configurations: configuration)

After doing this:

all existing data is present;
new data can be created successfully;
if I run an older build that still points to Application Support, SwiftData simply creates a brand-new empty store there, which suggests the original store was indeed moved successfully.

So from a local persistence perspective, this appears to work.

Remaining concern

Although this approach appears to preserve the SQLite store unchanged, I don't know whether it is actually safe for CloudKit.

Specifically:

Does moving the complete persistence package with FileManager preserve all CloudKit metadata needed for continued synchronization?
Is there any risk that CloudKit will treat the moved store as a different store and re-upload or duplicate records?
Are there additional files or directories that must also be moved besides:
- Store.sqlite
- Store.sqlite-wal
- Store.sqlite-shm
- .Store_SUPPORT
- Store_ckAssets
Is there an Apple-recommended migration path for this scenario that avoids introducing a temporary Core Data model purely to move the store?

In other words:

What is the recommended migration path for an existing production SwiftData application using an explicit SQLite URL to move into an App Group while continuing to use CloudKit?

One additional question

The SwiftData documentation provides two different ways to configure persistent storage:

ModelConfiguration(
    groupContainer: ...,
    cloudKitDatabase: ...
)

and

ModelConfiguration(
    url: ...,
    cloudKitDatabase: ...
)

My understanding is that when using the groupContainer initializer, SwiftData may automatically handle moving the persistent store into the App Group when the application is updated.

However, when using the url initializer, the application is explicitly responsible for choosing the store location.

Is that understanding correct?

If so:

Is there any supported automatic migration mechanism when using ModelConfiguration(url:), or is manual migration expected?
If manual migration is expected, is moving the complete persistence package (.sqlite, -wal, -shm, .Store_SUPPORT, Store_ckAssets) before creating the ModelContainer the recommended approach?
Or is there another Apple-recommended migration path for this scenario?

My related posts/questions