As for the transition to SwiftData from Core Data with CloudKit enabled, there are a couple of considerations. You are already following the first one by using the replacePersistentStore method. Using migratePersistentStore will create duplicates in our data. The second one is the speculation that app might freeze during migration if iCloud is disabled. That is why you might want to turn off the sync while the migration is running.

What is fascinating is that when you start a fresh SwiftData project and decide to implement widgets via an app group, the new framework copies the store file to the shared container automatically. However, this does not happen if we move from Core Data to SwiftData and use the old .sqlite file. I wish somebody from Apple commented on that. Is that by design, or is this a bug?

That solution works. However, what if we want to remove the Core Data file? Leaving the Core Data model obligates us to keep two models in sync, which can become cumbersome.

let configuration = ModelConfiguration("Something.sqlite", schema: fullSchema). This line of code will cause the creation of a database file like this: Something.sqlite.store. I highly doubt that this is what we want. Also, it doesn't look like SwiftData generates a .store file based on the Core Data's .sqlite file on my end. I've tested it many times. I always get an empty database. I then need to point SwiftData to the old .sqlite file used by CoreData with an explicit URL.

No, there is a supported way to bind the scroll position value to a specific time unit. Richard Wei from the Swift Charts team describes how to make scrolling snap to the first hour of each day in this WWDC23 session starting from 8:40. The API for this functionality is the following line of code: .chartScrollTargetBehavior(.valueAligned(matching: DateComponents(hour: 0)))