Thank you again for the clarification. Based on your recommendation for iOS 17–18, I implemented the migration as a one-time file-system move before creating the ModelContainer. I also took your suggestion of placing the database inside its own folder within the App Group, so the migration simply moves the entire persistence package into that directory before SwiftData is initialized. In case it's useful to anyone else who comes across this thread, here's the implementation I've ended up with: let modelContainer: ModelContainer = { let schema = Schema([ MyModel.self ]) let fileManager = FileManager.default let storePrefix = "Store" let storeName = "\(storePrefix).sqlite" let appGroupID = "group.com.example.myapp" let applicationSupportDirectory = fileManager.urls(for: .applicationSupportDirectory, in: .userDomainMask)[0] let oldStoreURL = applicationSupportDirectory.appendingPathComponent(storeName) guard let appGroupURL = fileManager.containerURL( forSecurityApplicationGroupIdentifier: appGroupID ) else { fatalError("App Group not found.") } // Store everything in a dedicated folder so future migrations only need // to move this directory. let persistenceFolderURL = appGroupURL.appendingPathComponent("Persistence", isDirectory: true) let newStoreURL = persistenceFolderURL.appendingPathComponent(storeName) if !fileManager.fileExists(atPath: persistenceFolderURL.path) { try! fileManager.createDirectory(at: persistenceFolderURL, withIntermediateDirectories: true) } // One-time migration from Application Support to the App Group. if fileManager.fileExists(atPath: oldStoreURL.path) && !fileManager.fileExists(atPath: newStoreURL.path) { let contents = try! fileManager.contentsOfDirectory( at: applicationSupportDirectory, includingPropertiesForKeys: nil, options: [] // Don't skip hidden folders such as .Store_SUPPORT ) for fileURL in contents { let fileName = fileURL.lastPathComponent let shouldMove = fileName == storeName || fileName == "\(storeName)-wal" || fileName == "\(storeName)-shm" || fileName == ".\(storePrefix)_SUPPORT" || fileName == "\(storePrefix)_ckAssets" if shouldMove { let destinationURL = persistenceFolderURL.appendingPathComponent(fileName) try! fileManager.moveItem(at: fileURL, to: destinationURL) } } } let configuration = ModelConfiguration(url: newStoreURL) return try! ModelContainer(for: schema, configurations: configuration) }()

Thank you for the pointer to makeManagedObjectModel(for:mergedWith:). My production app currently targets iOS 17, which is also the current recommended deployment target in Xcode, so that API isn't available to my existing users. What is the recommended migration path for applications targeting iOS 17–18? Specifically, if a SwiftData application has already fully migrated away from Core Data and no longer contains a .momd, should it: manually move the complete persistence package (.sqlite, -wal, -shm, .Store_SUPPORT, Store_ckAssets) into the App Group before creating the ModelContainer, or recreate/maintain a Core Data model solely to use replacePersistentStore, even though the application otherwise no longer uses Core Data? Reintroducing a Core Data model seems undesirable because the application has already gone through several lightweight Core Data migrations and, more recently, SwiftData schema migrations. Maintaining a second representation of the schema solely for a one-time file relocation doesn't seem like the intended long-term solution. If manually moving the persistence package is the recommended approach, does moving the complete package preserve all CloudKit metadata required for continued synchronization, or are there additional files or migration steps required to ensure CloudKit continues syncing the existing store without re-importing or duplicating records? In other words, what is the Apple-recommended migration path for existing SwiftData applications on iOS 17–18?

Hey Kyra, You must pay taxes from your developer proceeds in countries where you are a tax resident in a given year. Different countries have various criteria for being a tax resident. If you are based in the US and haven't lived anywhere else, you only have to worry about the US taxes. Furthermore, you don't sell any subscriptions personally. You designate that to Apple since it acts as your agent. And thus, the company handles the taxes in all the countries where your app is for sale. For more information, please read the Apple Developer Program License Agreement. And yes, you can choose where your app is available in App Store Connect. You can limit the availability of an app itself, purchases, subscriptions, or even promotional offers.