User Profile

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

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 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'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.

(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?

In the iOS 13.0 GM, leading and trailing swipe actions in a UITableView don't seem to work when using UITableViewDiffableDataSource. The delegate methods for providing a UISwipeActionsConfiguration don't seem to get called at all. This was also reported at https://stackoverflow.com/questions/57898044/unable-to-swipe-to-delete-with-tableview-using-diffable-data-source-in-ios-13. Has anyone else run into this issue?