If this actually works, I'll be amazed: FB23627358

Okay. Hours of commenting out swiftUI modifiers one at a time and A/B testing a bunch of nonsense leads me to the following: Treating the lazyVGrid cell content as the "label" of a button, OR applying a .hoverEffect to the same content, opting not to wrap it in a button, will degrade scroll performance on VisionOS. ScrollView will hitch as new rows come into view and may appear to vibrate as scrolled. These are symptoms I've seen in Apple's own apps, like Files, as well, so maybe it's more systemic. If that's not fixed but the end of the summer, I'll probably swap back to my UIKit implementation :\

Use a “soft“ scroll edge effect.

@DTS Engineer A reply on another post indicated that this would be fixed in “seed 4”, which maybe translates to beta 4?

Bump, anyone at Apple care to weigh in on this? I’d like to see something in the release notes if this is a “known issue”, or if it’s just not gonna happen this year.

Despite it being two years since the first batch of Schema‘s were released, I suspect we need to wait one more until we see any additions. Maybe there could be a half-cycle addition of new schemas?

Apple always seemed very stingy with regular size classes on iPhone as a way to differentiate the smaller and larger phone models Even when the smaller models became as large as previous large models Apple restricts them in software from showing UI elements like sidebars. I suspect some of that is going on here as well. https://www.reddit.com/r/ios/comments/1rh2vlk/ios_landscape_ui/

Hello?

I think having a .draggable definition or an attached .appEntity gives the system something to grab on to.

I am very interested in the solution to this. You may be told to create “photos.create” intent as well, so the system knows how to create a photo in your App’s domain, but even after doing that, this use-case of cross-app photo opening does not work for me. I’ve tried with images displayed in Safari. I’ve tried with Files in the files app. I‘ve tried with photos in the photos app. (In my case I’m trying to get “.addToAlbum“, not ”.setFilter”, to work.) It will only ever work from within my app working on an image made available by my app. I see it go from file -> photo -> addToAlbum as expected. Like you, though, the real utility is third party provided data ingestion. Related: FB23404394 FB23083759

That back button is driving me crazy. Why not use the system default?

Welp. iPhone 17 Pro simulator was able to make it work in resize mode... so... I guess it works fine Here's how I did it: @State private var tabViewWidth: CGFloat = .zero var horizontalSizeClass: UserInterfaceSizeClass { tabViewWidth > 736 ? .regular : .compact } var wantsSideBar: Bool { horizontalSizeClass == .regular } .onGeometryChange( for: CGFloat.self, of: { $0.size.width }, action: { tabViewWidth = $0 }) .environment(\.horizontalSizeClass, horizontalSizeClass) .tabViewStyle(.sidebarAdaptable) .defaultTabBarPlacementIfAvailable(wantsSideBar ? .sidebar : .automatic)

I am also curious about this! However, I think in this example, the "File/Folder" Scheme is explicitly about URL-based filesystem items. Now, your notes could be stored as files, and the "folders" could be literal folders. You could use two different Entities, each conforming to the appropriate Schemas and then allow them to be interchangeable with one another by implementing transferable on them. (I think!) I've gotten things like that to work for in-app-actions, but not yet for cross-app actions.

@DTS Engineer This sample project shows one LazyVGrid in a ScrollView, that looks fine – I'm curious to see if you find yourself needing to nest lazy stacks, there might be other ways to achieve the same result. I tried nesting lazyVgrids cause I wanted to try to have per-section column layouts. It was mess, though, with entire sections disappearing on scroll. Suggestion for perSection columns here: FB23162564 This exact situation is covered in our WWDC26 session I have watched this video. It is hard for me to know what about my views is "not stable enough". The cells in my feedback project (FB23182374) are either a VStack or HStack, and that's not changed at run time in the project. It's compiled to always be VStack. Does that "matter" to the internal mechanisms of LazyVGrid if that VStack never changes? I will experiment with this in my more complex app. Given the VStack never changes, the cell body always contains an image display area that has an .aspectRatio modifier on it (giving it a stable height for a given width) and a label with a line limit that reserves space. Is that stable enough for the internal workings of LazyVGrid? That image display area could show a placeholder depending on the loading state for that cell, but that does not impact the frame of the cell. It's all in the image-display-area that doesn't change size based on its content. Is that stable enough for the internal workings of LazyVGrid? Is there a way to introspect what lazyVGrid things is going on? I've tried backgrounds with random colors and during scroll the colors will stay constant, which I think means layouts are not happening? It's very frustrating to deal with these aspects of SwiftUI. We're on the seventh year now with no real CollectionView component.

I've gone over the videos, attended the QnA's, tried to follow the sample code, and Siri still won't invoke my intents that adhere to the Photos @Schema definitions. I've added AppIntentsTesting tests to confirm that my intents and entities are available from the application. I've confirmed that Shortcuts shows my intents actions, even the one that says my app has "Albums" even though it doesn't but I had to conform to it anyway because I have "galleries" and we can't make our own Schemas even after two years of that API existing.... I'm not convinced it actually works in Beta 1 and 2. I asked Apple several times what was not functional during the WWDC QnA sessions and they opted not to answer the question. Is anyone able to say what is / is not expected to be working for developer seed 2? I know it's still early in the cycle, but I'm not happy about the level of communication to developers about this one. It's impossible to introspect what siri is able to see on screen. It's impossible to ask what siri what it is able to do with a specific application. It's impossible to figure out why when you tell siri to do something it will straight up say it can't and then you say "yes you can, this app uses AppEntities" and then it will magically work. I figure I won't end up shipping the feature by the fall.