I finally worked out a solution to this problem, but it is a real hack. If you're interested in details, I can write it all up. However, in a nutshell, what I do is as follows: in any entity which contains an attribute that is used in the computation for the computed property, I use the validateForXXX methods to register changes. (The registration process is part of my CoreDataStack.) The entity which has the "computed" properties maintains real attributes with the computed values. The entity registers for notification for changes and performs the computations necessary to update the real (stored) values as appropriate. In this way, I am able to use a stored attribute (which can be the target of the find or sort operation) which is kept up to date. It's definitely kludgy (and requires more infrastructure that needs to be implemented correctly and consistently that I'd like), but I am finding it to be reliable. Again, I'll prepare a writeup if you're interested.

I put together a writeup of the technique I'm using. (Yes, it's kludgy and I would be delighted for someone to offer an improvement or a replacement.) If the writeup seems long (or insultingly detailed), please forgive me. I find writing this sort of thing helps me clarify my thinking. Be that as it may, since I can't attach either a Pages file or a PDF to this reply, I moved the writeup to my Dropbox. https://www.dropbox.com/s/nf2diu6haayn147/Pseudo-Transient%20Attributes.pdf?dl=0

I'm sorry, but this isn't right. localizedStandardContains(_:) provides CONTAINS semantics, not EQUALS semantics. The original poster (and I) want a case-insensitive test for equality. Using localizedStandardCompare(_:) == .orderedSame is not supported by the current (Xcode 15.0 beta 7) version of SwiftData, and the alternative suggested by Xcode's error messages (localizedCompare(_:)) is case-sensitive. The only thing I can think of at this point (not tested, by the way) is $0. attribute.localizedStandardContains(str) && str.localizedStandardContains($0.attribute) which is ridiculous. FB13051739

Hi, DMG, You're right - that is the obvious way to deal with the issue. I'm an old UIKit guy new to SwiftUI (and SwiftData and Observation Framework) so I was looking for a way to leverage the Observation framework, but a more traditional callback approach will certainly work. Very helpful. Thanks, Rick

Does let nilClub: Club? = nil let noClubPred = #Predicate<Member> { member in member.club == nilClub } work?

Thank you, Quinn. I was sort of afraid of that, because the security-scoped URL includes device-specific information (a UUID-based directory name). And it gets even worse, because it appears at openURL only works with external (https ??) URLs, not file URLs. (I'm going to file that as a bug report next...) So it looks like I'm going to have to re-evaluate the requirements of my app (and offer a less-capable product as a result).

Unless the situation has changed recently, it is my understanding that cascade does not work in iCloud+CoreData. Since SwiftData seems to be a layer on top of CoreData, one would suspect that cascade shouldn't work for it either. This is, I agree, a real pain. In CoreData, there were enough hook functions in NSManagedObject that one could manually handle the cascade operation, but I've been unable to find any suitable hooks that could be used.

You're absolutely right. I was trying to click-and-drag, which wasn't working. Definitely a case of pilot error on my part.

I'm having the same problem as everyone else, but I want to raise an additional concern. It is my understanding that the iPhone 8+ image will only be shown to users with a device that has that aspect ratio. So that means that only users of iPhone 8+ or earlier will see those screenshots. BUT, since the app required iOS 17+, they can't run the app. So providing the screenshots is essentially a case of BAIT AND SWITCH. By supplying the screenshots, the App Store is implying that the app is available when it is not. I don't want to speculate on Apple's motivation for doing this, but it makes ME look like the bad guy here. I don't think I should take the flack for this. What do you think?

With respect to the .externalStorage parameter, yes you can use it with CloudKit and it will do the right thing. I use that feature in my Stinkbug PM app and it works great.

To answer my own post — The problem is the ForEach function. Apparently you cannot use theid: \.self form with an editable row. I am guessing that editing the TextField affects the \.self ID and confuses the ForEach statement. The solution is to take the list of strings and use it to build an internal list of Identifiable structs that contain the strings. Then undo the process after completing the edits. This is messy but it works.

While I suppose you're right (I keep forgetting that a SwiftData "array" is really just a representation of an unordered Set), it is not what is causing the main issue of this post. If I remove that SoreDescriptor, I still have the crash.

Ziqiao Chen, Well, I really thought I'd tried that, but decided to try again so that I could answer you properly. My results have two cases: (1) In Preview, where I explicitly populate Teams with one record, the Preview crashes. (2) In Simulator (simulating iPadOS 18.0), where I do not yet have the code installed to create a new record (and hence have no records for the query to find), the app does not crash. Obviously, the next step is to add "New Teams" logic so I can test this issue further. I'll report again once I've added that logic.

Unfortunately, my situation is a bit more complicated. The result of tapping the "unscheduled" button is not to set the date to .now, but to allow the user to schedule the activity, presumably sometime in the future (but not Dec 31, 4000). Your solution requires two taps to set a correct date — first one to change "unscheduled" to .now, then the second to change .now to the date the user wants. While this will work (with your proviso about not being able to change the date back to "unscheduled", I'm still hoping for a cleaner interface.

These are really very nice solutions. Thank you so much for sharing the insights. (I was thinking about a different [and more complex] approach. You have made it clear that i was, as usual, overthinking things.