So, this actually works for me... If I right click on a gallery item on iPad and type "send this to " it will grab all items on screen and put them into a message. Here is what I have in my UICollectionView: public func collectionView( _ collectionView: UICollectionView, appEntityIdentifierForItemAt indexPath: IndexPath ) -> EntityIdentifier? { guard let item = dataSource?.itemIdentifier(for: indexPath) else { return nil } guard let fileIdentifier = try? FileEntityIdentifier.file(url: <URL>) else { return nil } return EntityIdentifier(for: <ENTITY>.self, identifier: fileIdentifier) } Note using the "FileEntityIdentifier" with the file's URL. Also, the that gets provided happens to conform to @AppEntity(schema: .files.file) My Transfer representations are just the following: public static var transferRepresentation: some TransferRepresentation { FileRepresentation( contentType: .image, exporting: { entity in print(" INT Exporting File Entity as File Representation") guard let url = try await entity.id.fileURL else { throw Errors.unableToRetrieveURL } return SentTransferredFile(url) }, importing: { received in let attributes = try? FileManager.default.attributesOfItem(atPath: received.file.path()) let creationDate = attributes?[.creationDate] as? Date let modificationDate = attributes?[.modificationDate] as? Date print("INT Attempting import of Image Entity from File Representation") return <ENTITY>( id: try FileEntityIdentifier.file(url: received.file), creationDate: creationDate, fileModificationDate: modificationDate, name: received.file.lastPathComponent ) }) }

Is there any evidence that Apple has made policy changes based on Feedback Reports? Historically it has seemed that only a sufficient amount of public outrage can move the needle. Please remember you can file feedback reports on our behalf and you are actually on Apple’s payroll when doing so. (We are not)

other than the fact that you can put AppKit and UIKit views into a swiftUI to fill some gaps in the framework, id say it’s kind of an entirely different way of making and thinking about app architecture.

Yeah, I’ve noticed this too. I can’t tell if it’s an oversight or just a macOS platform pattern. I would assume catalyst is… ”wrong”?

Anecdotally, this feels “right” to me. SiriAI and other AI tools only have so much “input context”, I don’t think many consumer models can ingest a textbook sized document without blowing through that window? Maybe they could in pieces? idk!

@Frameworks Engineer Nearly every outside developer will tell you it’s not acceptable to coerce developers to deliver subpar experiences to users. What, the user then has to go through the refund process? No one wants that. The App Store should support mechanisms so users don’t accidentally download apps they can’t get the most out of. Don’t worry. I know you’ll take your 30% anyway.

I have updated ticket FB23627358 with a sample project that demonstrates the issue. You'll need to compile it to run it. Two tabs two and three use buttons for the cells, and apply hover effects respectively. Observe they have choppy scrolling while tab one is BUTTERY smooth. 🧈

Keep replying with your code updates and I'll help you get something working. While SwiftUI has some difficult parts, it is not "difficult" it's just "different". It's important to remember you're not making views, you're just telling the SwiftUI runtime system how to make views, and it can be picky.

Menu Bars are one of the three most confusing aspects of SwiftUI app development imo. Imagine you had a multi-window app and each of those windows have an instance of your content view. Maybe you want a specific window to show the file import view. Maybe you only want one window to use the result of said import. It’s probably the active window, since that’s what the user is interacting with. There’s a way to achieve this and it is the technique that I would recommend. In an extension on the FocusedValues enum, I declare a Binding. You can probably do this with an @Entry too. var fousedWindowSheet: Binding<FocusedWindowSheet?>? { get { self[FousedWindowSheetKey.self] } set { self[FousedWindowSheetKey.self] = newValue } } This allows focused windows to provide a hook that the menu bar can then leverage to present things. You content view can do this with the following: .focusedSceneValue(\.fousedWindowSheet, $showingFocusedWindowSheet) (it provides it's own @State to the focus system and can use that state in its own .sheet modifiers. Okay, sure, but how does the CommandGroup get access to the focused value that's set by the actively focused scene? Boom @FocusedBinding(\.fousedWindowSheet) private var focusedWindowSheet I declare one of those in a struct that conforms to Commands and I pass an instance of that into .commands struct MyCommands: Commands { @FocusedBinding(\.fousedWindowSheet) private var focusedWindowSheet var body: some Commands { CommandGroup(after: .newItem) { <blah blah blah> } } } .commands { MyCommands() } Honestly, this was a poorly structured dump of information more than a "guide" on how to do this. I hope, though, that the keywords and technique of using FocusedSceneValue in conjunction with FocusedBinding get you on the right track! It also sounds like you may need a refresher on how State propagates through swiftUI applications. View's are initiated on demand, and body methods are called at will by the system. If you want state to last beyond those moments of re-invocation it has to be stored in an @State somewhere.

So... bit of a mind-bender, but you're losing your "self" reference, and possibly leaking timers into the runloop. SwiftUI views are not actually views, but more like view-blueprints, that can be asked for a view. This means they can be inited as needed by the system and body can be called as needed. This means your setupTimer method is at risk of getting called multiple times and timers could keep getting put into the run loop. It also means that the "self" reference inside the timer closure is super dubious. Throwing it into an observable controller that's stored as a state object property will keep the state more constant and it will work. (I'm leery of the .task method in this example and it's just to get the timer started. You probably want debounce protection if you're gonna store em in the runLoop. You should probably seek an alternative async/await solution for that) @Observable class Controller { var referenceDate: Date = Date() init() { } func setupTimer() { let calendar = Calendar.current guard let triggerDate = calendar.nextDate( after: Date(), matching: DateComponents(hour: 20, minute: 16, second: 0), matchingPolicy: .nextTime ) else { return } let timer = Timer(fire: triggerDate, interval: 0.2, repeats: false) { _ in DispatchQueue.main.async { self.referenceDate = Date() } print("runLoop!") } RunLoop.main.add(timer, forMode: .common) } } struct ContentView: View { @State var controller = Controller() var body: some View { VStack { Text("Ref time: \(controller.referenceDate.formatted(date: .abbreviated, time: .standard))") Button("Huh") { controller.referenceDate = Date() } } .task { controller.setupTimer() } } }

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.