I'm starting to work on updating my code for Swift 6. I have a number of pieces of code that look like this: private func updateModel() async throws { try await context.perform { [weak self] in // do some work } } After turning on strict concurrency checking, I get warnings on blocks like that saying "Sending 'self.context' risks causing data races; this is an error in the Swift 6 language mode." What's the best way for me to update this Core Data code to work with Swift 6?

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

After installing Xcode 14 beta 3, the iOS 15 simulators in my Xcode 13 install seem to have vanished. Adding new ones in the Devices and Simulators window does nothing. Deleting both Xcode installs and installing a fresh copy of Xcode 13.4.1 also didn't help. Seems like I'm not alone: https://twitter.com/mattkiazyk/status/1544761694341451776 https://twitter.com/bourvill/status/1544797153104625664 Anybody have ideas for how to fix? Feedback filed: FB10570079

I'm trying to debug a couple of crash reports for a Mac Catalyst app and seem to be unable to symbolicate my crash reports. In the Xcode Organizer, I see unsymbolicated lines for my app, despite having the original archive for the build in question. A search for the relevant dSYM (using the process from https://developer.apple.com/documentation/xcode/adding-identifiable-symbol-names-to-a-crash-report#Locate-a-dSYM-Using-Spotlight) yields no results. Unlike iOS builds, the "Download dSYMs" button isn't present in the organizer, nor is the option to download dSYMs from App Store Connect. I assume this is because macOS apps don't use bitcode. The app's Debug Information Format is set to DWARF with dSYM File. Has anyone else run into this issue? Any ideas about how I can symbolicate the crash logs?

I want to use the original_application_version value from the app receipt to grandfather some features for users who are first-time users vs existing users. In the Receipt Validation Programming Guide, the field's notes are as follows: This corresponds to the value of CFBundleVersion (in iOS) or CFBundleShortVersionString (in macOS) in the Info.plist file when the purchase was originally made. In the sandbox environment, the value of this field is always “1.0”. I'm unsure which value to expect in Mac Catalyst, since it's a UIKit (and thus iOS)-based app being distributed through the Mac App Store and run on a Mac. My instinct is that the store is determinative, and thus to expect the macOS CFBundleShortVersionString on the Mac. Unfortunately, since the value is always "1.0" in the sandbox (including TestFlight) I don't have a good way to test this. Does anyone have any real-world experience that can shed light on what format I can expect?

I’m working an update for an app that will increase the minimum iOS version that the app supports, and I’m trying to determine whether users on an older version of iOS will still automatically receive updates for the last supported version. For instance, suppose I released version 1.8 of my app last week, which supported iOS 12 and above. This week, I release version 2.0, which increases the minimum iOS version to 13. Would a user running iOS 12 who hadn’t yet installed version 1.8 (which was the last to support iOS 12) still see version 1.8 in the App Store updates area, and receive the update automatically if they have automatic updates enabled? (I know they wouldn’t see or receive 2.0, since that requires a newer version of iOS.) TLDR: Do users on an older version of iOS still receive updates as far as the highest app version that supports their version of iOS, without having to go manually download them?

(I also posted this on StackOverflow at https://stackoverflow.com/questions/60196113/core-data-migratepersistentstore-crash-with-perform-performandwait)I'm attempting to use `NSPersistentStoreCoordinator.migratePersistentStore(_:to:options:withType:)` to move a persistent store from one location to another, using an approach like this: https://useyourloaf.com/blog/moving-core-data-files/. (My overall goal is to create a backup, so I'm also drawing on the Ole Begemann's work (https://oleb.net/blog/2018/03/core-data-sqlite-backup/), which is in turn inspired by a previous SO post (https://stackoverflow.com/questions/22670273/copy-backup-persistent-store/22672386#22672386), but the problem I encounter is the same in both cases.)let sourceStore = ... // NSPersistentStore let backupFileURL = ... // URL try self.migratePersistentStore(sourceStore, to: backupFileURL, options: [:], withType: NSSQLiteStoreType)When calling `migratePersistentStore`, Core Data loads objects into memory, triggering a call to `awakeFromFetch()` on each one. That uses some memory, no surprise, but not necessarily a big deal in this case.However, if `awakeFromFetch()` happens to do something that uses `NSManagedObjectContext.perform` or `NSManagedObjectContext.performAndWait`, the app crashes while moving the persistent store with an error like this one:*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'Can only use -performBlock: on an NSManagedObjectContext that was created with a queue.'As far as I can tell, the crash occurs because during the move/migration, `awakeFromFetch()` is being called in an NSManagedObjectContext that uses the deprecated `confinementConcurrencyType` and calls to perform/performAndWait aren't permitted on with that concurrency type.(Here's a super simple example `awakeFromFetch()` that I'm using as a demonstration:)public override func awakeFromFetch() { super.awakeFromFetch() managedObjectContext?.perform { print("Hello, world!") } }I could theoretically work around this by checking the context's concurrency type and only wrap calls in perform/performAndWait if it's not a confinement context, but that seems both unwieldy and out of line with best practices.Does anyone have a recommendation for how to handle this? Is there a way to prompt `migratePersistentStore` to use a different concurrency type?

I'm running into trouble setting up sync using NSPersistentCloudKitContainer on an existing app. The app doesn't seem to sync data that was added to Core Data prior the app's iOS 13 update. For instance:1. I install an existing, pre-iOS 13, version of the app and create several records that are stored in Core Data.2. Over that existing install, I install the updated version that uses NSPersistentCloudKitContainer and create some additional new records.3. I install the same new version on a second device.Results: Records created in step 1 don't appear on the second device, but records created in step 2 do.Is there a step I'm missing in order to get existing data to sync? I'm wondering if this has something to do with the persistent history token, but I'm unsure how to tell NSPersistentCloudKitContainer it should "start over" on first launch.

Is there a way to pause or disable syncing via NSPersistentCloudKitContainer at runtime? I want to give my users the option to enable or disable syncing, but there doesn't seem to be a good way to do it. I tried reloading the persistent stores and setting the store description's cloudKitContainerOptions to nil, but if I do that after first initialization, I get an error:error: Store opened without NSPersistentHistoryTrackingKey but previously had been opened with NSPersistentHistoryTrackingKey - Forcing into Read Only modeAnyone know of another way to do this?I submitted a request via Feedback Assistant for a flag to enable or disable syncing (FB6156182). I know the user could theoretically go into the Settings app and enable or disable iCloud access for the app as a whole, but that's not very discoverable, and disables all iCloud access. I'm looking for something a little more fine-grained (limited to the NSPersistentCloudKitContainer) and that I could control in my app's UI.