hi, your iteration is over the elements of a dictionary that has three key-value pairs: for (key ‚numbers) in interestingNumbers { // interestingNumbers is not an array dictionaries are not ordered; so one time you may get Fibonacci, Prime, Square ... another time it may come out in a different order. this is exactly the behavior that you're seeing. hope that helps, DMG

hi, i'm getting something similar in behavior related to toolbar items for the keyboard, although it's not exactly the same. (i am using Xcode 15 official release, not a beta or the RC.) in my case, i have a view that can be shown either by navigating to it, or opening it in a sheet (wrapped inside a navigationStack). when the view is navigated to, the button i place on the keyboard (to dismiss the keyboard) works as expected. when the view is opened in a sheet (view is wrapped inside a navigationStack), the button does indeed appear, but it is disabled. i'll try to put together a minimal example to file a feedback, but i'll be curious to see if there are more reports. DMG

spent the weekend playing with something similar ... and i think that two things that don't work with #predicates are (1) you can't use computed properties (makes sense if you think about it, since these are not key paths referencing properties of a model as stored on disk) and (2) you can't query using relationships (this is something i expect will get fixed). //DMG

hi, the error message about "parameter of type 'FormStyleConfiguration'" does not give the precise cause of the issue. in short, error messages from the SwiftUI compiler can be confusing and simply not point you to the real issues, especially when you have lots of code defining the view where the nesting levels go pretty deep. in this case, commenting out the first Section will better point you to the problem that exists in the second section. indeed, the second Section in your DetailView starts with ForEach($clients.enclosures) { .... but you have not defined an enclosures property on Client, which should be a @Relationship, and Enclosure might want to have an inverse @Relationship property back to Client. hope that helps, DMG

you do have item marked as an @ObservedObject in the ItemView, yes ?

hi, i don't think that SwiftData will do this automatically for you (there are aggregate functions available in Core Data for this, i think, but they are not there yet in SwiftData -- if they are, i'd like to know about that). in the meantime, yes, just go ahead and fetch all records, but limit what's fetched to only the integer property you're interested in. for example, i have an app concerning a model type Location and a model property position: Int and i want to find the maximum position value among all Locations. private func lastLocationPosition() -> Int? { var fetchDescriptor = FetchDescriptor<Location>() fetchDescriptor.propertiesToFetch = [\.position] // only the positions values come back fully realized do { let locations = try fetch<Location>(fetchDescriptor) return locations.map({ $0.position }).max() } catch let error { print("*** cannot fetch locations: \(error.localizedDescription)") return nil } } it would be easy to slightly modify this function to return a Location? that realizes this maximum value -- compute the maximum and just find the first object among the fetched locations where the maximum is achieved, returning it instead of an Int?). (all remaining properties of the Location returned will be faulted, so you can use the model object with no problem: any property values you want will be faulted in when needed.) hope that helps, DMG

instead of @Query var model: MyModel, did you mean @Query var models: [MyModel]? a Query returns an array.

consider "How to Observe Data Changes in SwiftData using Persistent History Tracking" at Fatbobman's Blog from Nov 2, 2023 (fatbobman.com). DMG

hi, my guess on this is that you never inserted either model into the modelContext; linking them together either by appending the film to the director's films, or setting the film's director reference would cause an issue. as to which you should do in linking objects together, it used to be simple in Core Data: you could do either (and the other direction would bee handled automatically). however, for at least the early betas and the official release of Xcode 15 and iOS 17, it appeared to me that you were better off writing newDirector.films?.append(film) than film.director = newDirector, because the former was more likely to work with observation. (that could be fixed by now). finally, setting self.director = director in a Film's init() is probably a bad thing to do; i'd want to insert a new Film into the modelContext before setting the director reference. hope that helps, DMG

hi, my suggested answers are: (1) appropriate time to deploy? see (2). (2) Should it be done before beta testing via TestFlight? yes, you must move to production before users can test via TestFlight. (3) does that mean I won't be able to reset the schema if testers discover critical bugs related to the data model? well, this one's more nuanced. as you know, once you are in production, that CloudKit schema only allows additive changes (add an attribute to an existing entity, or add a new entity). if there are problems in the database schema, there's no reason you cannot make any necessary additive changes, and then simply ignore values of entities and attributes that are no longer needed. for example, if you want to change a relationship from one-to-one to one-to-many, add a new relationship between the two entities; read the existing one-to-one relationship's value; and set the new one-to-many relationship. if you really want to keep the CloudKit container trimmed, you could take the time to remove all objects of a given entity type (the entity type would still be in the CloudKit schema; there just would be no objects of that type), and you could set attributes no longer in use in a given entity to some small space-consuming value (e.g., "" for a String, or nil for a Data). nullify any relationships no longer in use. i would suggest that you consider an explicit version number attribute to all the entities in your schema, with default value 1 (or whatever is your current core data model version). if you do make (additive) changes in the future, you can update the version number; and you can later test this in code to know what record type you're working with and what fields it has by first checking its version number, and then use appropriate logic to work with the object. the best reference on this might be to start with David Stites's WWDC2022 video named "Evolve Your Core Data Schema". the last third of this covers the CloudKit issues. finally, if you really do want to reconfigure the data model once it's in production, could you possibly define the new version of your core data model, which takes care of the local data store ... but then assign a new CloudKit container to your app? i don't know the answer to this one, but perhaps you won't need go there. hope that helps, DMG

hi, downloaded the release version of Xcode 16.0 (16A242d) last night ... and today i ran into this warning.

thanks Ziqiao ... didn't remember about fetchUserRecord being available to get your user record. and thanks to jlilest ... i had thought of this, but then i need a stabile ID within the app before uploading any CKRecords (a little too late for that, unfortunately).