Your post is extremely interesting and definitely requires more thought on my part. It seems that what you're doing is to build a FocusCoordinator, conceptually similar to a Navigation Coordinator (although I think that there may be some missing APIs preventing a comprehensive solution. My immediate interest is on tab-navigation and I have some new information to offer about it. It turns out that in most cases, sending a <tab> to a focueed TextField will cause focus to change, BUT if the TextField is instantiated with the axis: AXIS parameter, the <tab> is added to the TextField body instead. I don't know how Apple will classify it, but I'm calling this a bug and have reported it. (FB20505919).

This is a very nice addition to SwiftData, but there is still a problem (which I didn't mention in the original post). To the best of my knowledge, CloudKit still does not support (or enforce) unique properties. So, unless I'm missing something, this solution only works if you don't want take advantage of iCloud data synchronization services. Or am I missing something?

Thank you for your help. I think this fixed it. Following your directions, Checked Xcode's Apple Accouts - Looked ok Set up a new project with a new AppID and CloudKit container. Worked. While in that new project, changed AppID and CloudKit container back to the problem values. FAILED. Logged in to Developer portal. No warnings or error messages and no pending agreements. Followed steps from TN3164. iCloud was checked. However, the option was "Compatible with Xcode 5". Changed it to "Include CloudKit support" and saved. Forced a reprovisioning by unchecking and rechecking the Automatic Signing feature in Xcode. WORKED. (I believe I said previously that this was an OLD app...) Thank you for your help. (I'll copy this into a reply in the FB to complete your records.)

I created a sample project demonstrating that .onScrollGeometryChange returns no data when applied to List, Form, or TextEdtior. FB19922481

Just a quick reply -- I'll put together a sample project for the feedback report and have it for you tomorrow (Wednesday). I am using Xcode 16.4 running on macOS 15.7 working with a project where the Minimum Deployment Target is iOS 18.0 (I changed it from 17.0 to try using the .onScrollGeometryChange API). I see the problem (i.e., listHeight = 0 on both #Preview and on the Simulator (running the iPad mini (6th generation) 18.1 simulation. More tomorrow -- hopefully with a sample project and an FB#.

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.

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.

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.

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.

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