Drew, some quick comments, since i cannot see your code (if it were available on GitHub, that might be of interest). in the Core Data model editor, find the attribute date in whatever entity you are working with and check that its Type shows as Date. if it shows as String there, just click on the String value and choose Date as the Type from the pull-down menu. (you may already have done this, but i cannot tell from your question.) so Core Data knows the values are dates, and sorting with ascending: false will give most recent dates first, oldest dates last. Xcode will give your app/program access to the date attribute as a Swift variable var date: Date? defined on the class object for your entity. notice that this is an optional Date in Swift, so treat it accordingly when reading it. all your existing code that reads from the date attribute or assigns to the date attribute should be working with real Date objects in Swift. you cannot assign a String to a Date? object; but really, other than for display purposes, you should not be working with string values of dates in your code anyway, since constantly translating back and forth between Strings and Dates is hard. hope that helps, DMG

hi, you do not show the definition of your Core Data entity, nor the type of its attribute "date." since the list of dates appears to be sorted alphabetically, i am guessing that you defined the date attribute in Core Data as a String (not as a Date) and that you are storing strings in what you call "date." that would explain the result above. (BTW: to have Core Data sort by the Date type, you would want "ascending: false" for the NSSortDescriptor so that the most recent date comes out first.) hope that helps, DMG

hi, ... this may not directly answer your CloudKit sharing, but what you may be asking is how to place all Core Data Folder and Comment objects into a local persistent store configuration, and allItem objects into a cloud configuration that is shared with iCloud. if that's the case, you cannot implement direct relationships between configurations, so then you might: in every Item, store the id: UUID of the Folder it belongs to (you do put UUIDs into your Core Data entities, yes?) ... sort of a parentID, and in every Comment, store the id: UUID of the Item it belongs to, again, essentially a parentID. you can then finesse the relationships, say for an Item, finding its parent Folder by doing a Core Data fetch for Folder objects whose id matches the Item's parentID; and similarly, you can locate the Comments associated with an Item by doing a Core Data fetch for Comment objects whose parentID matches the Item's id. Also take a look at this Apple Sample project on how to handle separate stores in Core Data. hope that helps, DMG

hi, the easiest, fastest way might just be to change the definition of numbers, so that the elements appears with the frequencies you like. since we're talking 1/20-ths here (multiples of 5%), give the array 20 elements: let numbers = ["1", "1", "2", "2", "2", "2", "3", "3", "3", "3", "3", "3", "4", "4", "4", "4", "4", "4", "4", "5"] if let pickedNumber = numbers.randomElement() { print(pickedNumber) } there are more general ways to do this, but keep it simple for now .. hope that helps, DMG

hi, your ViewModel simply needs to use an NSFetchedResultsController to hook into Core Data, and keep the array of Core Data objects that you would ordinarily define in the View (using @FetchRequest) as a @Published property. whenever the resultsController fires, update the array property. be sure your View keeps a reference to the ViewModel as an @ObservedObject. hope that helps, DMG

hi, why not simply write the predicate as NSPredicate(format: "clientId == %@", clientId! as CVarArg) // i would think the force unwrap would help here ? i have used this; it works. hope that helps, DMG

hi, you can certainly do a fetch directly with core data; but if you expect your class object to find out about changes in Core Data and act like you had a @FetchRequest, you would want to use an NSFetchedResultsController in your object to see changes over time. hope that helps, DMG

hi, i think you should take the error message as is and paste the string NSSecureUnarchiveFromDataTransformerName directly into the Transformer entry where it indicates "Value Transformer name". that will do it. as to what this means in the future: who knows? i doubt that it will go away. this has more to do with security rather than any feature that will be changing. as for best practices: transformable data is not directly searchable in Core Data. that doesn't mean that you cannot search by dates, pulling all records and then, one-by-one, examining its array of dates. it's just that Core Data cannot do it with a simple fetch. hope that helps, DMG

hi, since you are using NSPersistentCloudKitContainer, you might want to take a look at Apple's page on Linking Data Between Two Core Data Stores. this provides a mechanism so that you can load up what i think you are calling "base values" in a local store, separate from the store that is mirrored to iCloud. this would solve the problem of loading base values on one machine, moving them into the cloud, and then trying to figure out on a second device how to prevent them from being reloaded from iCloud. hope that helps, DMG

Yup, it's one year later, and things have changed. i did indeed find out that iCloud does not work with an Ordered relationship. in the end, there were only two, fixed image data objects i needed: one for a 48 by 48 image, and one for a 144 by 144 image. i just made them attributes of an Entity, rather than separate Entities via a relationship that are indexed 0 ... 1, with a reasonable compression value. i marked the attributes in Core Data as "Allows External Storage." if i run into problems in the future, i will come back to it (!) DMG

hi, change the declaration var item: Item in DetailView to @ObservedObject var item: Item changes to the item will then trigger a view update for the DetailView. that should do it, i think. hope that helps, DMG

hi, it may be as simple as not turning on history tracking. in my code, i usually have these lines right after creating the NSPersistentCloudKitContainer: // (1) Enable history tracking. this seems to be important when you have more than one persistent // store in your app (e.g., when using the cloud) and you want to do any sort of cross-store // syncing. See WWDC 2019 Session 209, "Making Apps with Core Data." guard let persistentStoreDescription = container.persistentStoreDescriptions.first else { fatalError("\(#function): Failed to retrieve a persistent store description.") } persistentStoreDescription .setOption(true as NSNumber, forKey: NSPersistentHistoryTrackingKey) persistentStoreDescription .setOption(true as NSNumber, forKey: NSPersistentStoreRemoteChangeNotificationPostOptionKey) hope that helps, DMG

hi, we do not see the definition of category in this view, but i am hoping that it would ideally be @ObservedObject var category: Category // not an optional, so reference category.CitemsArray in the ForEach you should know that changing a property of one of the category's associated items is not seen as a change to the category object itself, and it will not trigger a visual update of the view. when you do item.done.toggle() in the .onTapGesture, consider registering an explicit change on the category object with category.objectWillChange.send() hope that helps, DMG

hi, instead of writing from = filter.criteria.from ?? "" to = filter.criteria.to ?? "" you should be writing _from = State(initialValue: filter.criteria.from ?? "") _to = State(initialValue: filter.criteria.to ?? "") this is a syntactic issue with @State: you need to initialize the property wrapper, not its value. hope that helps, DMG

hi, did you set NSPersistentHistoryTrackingKey and NSPersistentStoreRemoteChangeNotificationPostOptionKey, along with automaticallyMergesChangesFromParent and the mergePolicy? i use this code. guard let persistentStoreDescriptions = container.persistentStoreDescriptions.first else { fatalError("\(#function): Failed to retrieve a persistent store description.") } persistentStoreDescriptions.setOption(true as NSNumber, forKey: NSPersistentHistoryTrackingKey) persistentStoreDescriptions.setOption(true as NSNumber, forKey: NSPersistentStoreRemoteChangeNotificationPostOptionKey) container.loadPersistentStores(completionHandler: { (storeDescription, error) in ... }) container.viewContext.automaticallyMergesChangesFromParent = true container.viewContext.mergePolicy = NSMergeByPropertyObjectTrumpMergePolicy there's also a recent article by Becky Hansmeyer (h ttps://beckyhansmeyer.com) that may be helpful. hope that helps, DMG