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.

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.

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?

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

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.

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

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

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

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

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

Ah, but if your Mac isn't equipped with a trackpad, a two-fingered swipe isn't possible. I think I'm going to need to implement a contextual menu or something like that. Another possibility: Since we need to add (for compatibility with common expectations of Mac UI) click-to-select + delete (or forward-delete) to delete a row, maybe a click-to-select + "something-else" to edit it. For cases where "edit" and "show detail" are similar, "something-else" might be return-key.

Here is my solution: (1) Using Xcode 12 beta 5, in IB, I set the properties of the split-view controller to be: Display Mode: Two Columns Beside Behavior: Tiled (<== this is important) Then I use the following code for the view controller: SplitViewController - https://developer.apple.com/forums/content/attachment/957df126-8068-465f-9c00-fe20df3bcd13 It seems like the key to making this work was to change the behavior from "Automatic" to "Tiled".

I've been reading some other posts and have the following idea. I'd appreciate any comments about whether you think this is workable:When performing the once-only initial seeding of the Core Data store, explicitly turn off History Tracking. Once the initial records have been saved, turn it back on.Then, the seeded values will never be synched to the cloud, but all new records and all modifications of the seeded records will. And this should occur on all devices sharing the data. Does this sound like it will solve my problem?