@DTS Engineer It looks like the system, when invoking an OpenIntent, knows the input target of the intent, and knows the "ID" of the "target". In my case it's the special FileEntityIdentifier Using the code on the documentation will not work because func entities(for identifiers: [FilesEntity.ID]) async throws -> [FilesEntity] { [] } is not converting the system provided FileEntityIdentifier to a "FilesEntity", so there's no target to invoke the OpenIntent with. Here's the fix for that: func entities(for identifiers: [FilesEntity.ID]) async throws -> [FilesEntity] { identifiers.map { FilesEntity( id: $0, creationDate: nil, fileModificationDate: nil ) } } I've resolved this and ALSO provided the OpenIntent using the "AppShortcutsProvider". Otherwise it does not appear in shortcuts. The good news: When invoked from the provided shortcuts area it works! I am not able to add it to a custom-shortcut as an action, though, I can only invoke it directly from the provided shortcuts card. Questions Now that I know the OpenIntent works, how can I invoke it with Siri? It seems any phase with "open" in it still just opens my app. Does the OS provide a "file" to Siri anywhere? How can I know this? I've tried a quick looked file in the Files app and phrases like "Open this in ".

The documentation indicates that you should use performDrop to load from the item provider. enter and exit is only to indicate that a drag operation is targeting a view.

I think it will be called on re-build if the identity of the view is the same, so SwiftUI considers them the ”same”

:facepalm: I needed to call .compositingGroup() before applying the .layerEffect. I'm gonna go lie down.

Bump? Any framework engineers know how to use this stuff?

I think you need to explore “deep linking” solutions in your app. That’s the concept of entering the application at a screen lower than the first view. I chose to solve it with a singleton but I think there’s a new @Dependency you can use these days.

@DTS Engineer Non-Catalyst apps deployed via the Mac App Store may also use an iOS-style app group name (group.*) as long as that group is registered to the app’s team. This is the first criterion mentioned in the release notes (“the app is deployed through Mac App Store”). Does this apply for dev-builds running directly from Xcode? Like, if a build from Xcode is prompting users to "Allow" data from other apps, will it still prompt if it's installed from the mac app store? My macAppStore app is prompting me to allow. It's using group.* because it used to be a catalyst app.

Workaround: Assign a delegate and implement: func previewController(_ controller: QLPreviewController, transitionViewFor item: QLPreviewItem) -> UIView? { UIView() } If anyone at Apple would like this fixed, please file a radar.

:facepalm: Just needed that extra 5 minutes of search-fu. .widgetAccentedRenderingMode(WidgetAccentedRenderingMode.fullColor

FB14172673

Any framework devs have an answer? I read that there was supposed to be a larger presence on the forums this summer.

Discovered that this is also happening to my heavily-image based widgets. Is there a new API in iOS18 to account for this? I see that the Photos app widget appears to correctly tint the displayed images.

It seems that I can simulate selection by tracking it all myself, but I don’t think I can inform the contextMenu closure to perform the nice aggregation animation that users are used to. Maybe I’m missing something or maybe I gotta wait a year+

I say don't bother. While the SwiftUI framework makes things that resemble an OutlineView, they fall very very far short of the flexibility offered by the Appkit and UIKit frameworks. Notably, if you want users to be able to rearrange the items between parent / grandparent items, beware. You will not be able to do so in a way that users find intuitive, if at all, in pure SwiftUI. I requested the ability to be able to drag items from one SwiftUI ForEach to another after WWDC22 revealed no improvements. (FB10064943). For me, this inhibits making a rock-solid sidebar, and while the TabView APIs this year get closer, they come with other design baggage I'm not sold on yet. If you've already got an AppKit implementation, just drop that into SwiftUI land via the representable APIs. There are many places in SwiftUI that will get you 80% of the way to a great user experience, but the other 20% requires a fully bespoke solution that won't resemble the system provided UIs or support accessibility considerations. Why it's taken over 2 years to add the ability to drag things between sections I'll never know. Probably deprioritized.

FSKit but it’s not documented yet and there’s no sessions about it.