It turns out that the problem isn't with GeometryReader, it's with LazyVGrid. I'm not clear on why, but my grid with 5 columns doesn't always report the same size. I can make it work by adding a 6th column that doesn't get used in the view. Very odd.

The error I'm getting: Thread 1: Fatal error: <UpdateCoalescingCollectionView 0x3037efc30> is stuck in a recursive layout loop. This can happen when self-sizing views do not return consistent sizes, or the collection view's frame/bounds/contentOffset is being constantly adjusted. To debug this issue, check the Console app for logs in the "UICollectionViewFeedbackLoopDebugger" category. Collection view: <SwiftUI.UpdateCoalescingCollectionView: 0x156f96a00; baseClass = UICollectionView; frame = (0 0; 852 149); clipsToBounds = YES; autoresiz

Another oddity: GeometryReader doesn't just read the geometry. It actually takes up space in the view! I suppose that's a feature, not a bug, right?

For anyone still having this issue: Debug -> Debug Workflow Uncheck "Always Show Disassembly"

I got it to work by building from Xcode. Simply letting Apple build it when you push a commit wasn't good enough! Well, at least this time. We'll see on the next try... maybe we will need some other incantation.

I found this on Stack Overflow: *** SO *** Info.plist is not visible as a separate file until you add non-standard values to it Do you see the Info.plist in your project? Do you see the values of it reflected under [Blue Project Icon in Project Navigator] -> Targets -> [Your Target Name] -> Info? Did you try to add a custom value to it? (this will trigger it to become visible) See: https://stackoverflow.com/a/67896587/2804585 *** end SO *** Maybe you're thinking it's solved? Think again! Now it reports no errors or warnings on appstoreconnect, but it still won't let me add the build to my submission, so I can't add for review!

I tried adding App_Uses_Non_Exempt_Encryption NO to Build Settings, but that did nothing.

I have to say that this is yet another serious flaw in the Swift framework. You have to write your code on the assumption that the initializer for a view may be called multiple times, but this is highly inefficient and it causes a problem where you can easily have race conditions. I see no way to have nested models where an item can link to an array of items, for example, because that requires a query in an initializer that can create an infinite loop. Combined with Xcode's terrible debugging, this is infuriating.

It looks like SwiftUI is pre-drawing the navigation links when the screen is loaded, and since one of those links is to the same screen with (usually) a different item, it gets repeated infinitely. If anyone knows how to stop that without having to use a nearly identical view, please post it here.

I thought that I'd solved it by changing the AddItemView toolbar to this: .toolbar { Button("Save") { let tmp = Item(name: name, parent: itemParent) if self.itemParent == nil { context.insert(tmp) } else { itemParent?.children.append(tmp) } try? context.save() dismiss() } } That works for the first layer, which is why the image below has items B and C, but clicking on them causes another infinite loop, this time with the SubItemView calling itself.

It wasn't the query, it was the children array in the Item model competing with the query.

Gah! It's because I don't have a query in the view. It's just taking data from the caller.

I found a video showing that you need to archive from Xcode. Why that wasn't the first thing you see when deploying, I'll never understand. Now, I'm trying to get my wife's phone to be a test user, but it's an old phone using IOS 15, so it's crashing when trying to accept iCloud terms and conditions. Such fun!

It won't show up in the project or the Finder. Try using Terminal: cd /path/to/project/.git ls

What files are missing? It looks like you have the beginnings of a project there. Certainly more than the boilerplate that you get when you create a new project.