Can you clarify how you are testing the links? I've found that the simulator will not always open the links in my app, especially via Safari opening it in. The most reliable method for me has been to put the link into Reminders or another system app and then tap on it.

It's a known issue and has been reported. See: https://forums.swift.org/t/swift-5-10-concurrency-and-xctest/69929/12 https://github.com/swiftlang/swift/issues/72181 You'll have to comment it out for now or not enable Swift 6 complete concurrency checking.

Same here after having an app approved with multiple icons in the binary.

Specifying an arrow direction on my bottomBar toolbar button makes the tooltip show up for me. .popoverTip(tip, arrowEdge: .bottom)

As far as I can tell, reexporting an AppIntent defined in a framework using AppIntentsPackage and includedPackages has never worked since it was introduced at WWDC23. @gohnjanotis @alexanderwe I believe the only solution is to add your app intents directly to your app target and also any other extension target that uses them, I was able to get my shortcuts showing up in Shortcuts doing this. Unfortunately this workaround wouldn't work for an AppIntent defined in an SPM package like in the original question prompt.

Not fixed in RC unfortunately.

Hi @conradstoll, any chance you figured out anything here? We're seeing the same crash logs after changing our Ventura + Catalyst app to a SwiftUI with toolbars app.

Thanks @Frameworks Engineer, I've filed FB12495249. I've narrowed the problem down to using an App Intent and have reproduced with a barebones sample project. Does not seem to be related to SWIFT_EMIT_LOC_STRINGS after all.

Agree, I'm seeing the same thing here. It looks like prefixing AppIntents. in the shortcut provider actually just hides the shortcuts entirely from the metadata parser. if you look at the built Metadata.appintents/extract.actionsdata in derived data, it's clear the AppShortcutsProvider is detected correctly but that the intents, entities, and queries are not detected from the underlying package / framework. Assuming a beta bug with the package intent re-exporting at this point, too.

+1. I have roughly the same setup except I'm using a dynamic framework instead of a SPM package. I got the same error when I reference my AppIntent in a AppShortcutsProvider. Weirdly enough I just discovered that prefixing all the AppShortcut types with AppIntents fixed the issue for me. import AppIntents import MyIntentsFramework struct MyShortcutsProvider: AppShortcutsProvider { static var appShortcuts: [AppIntents.AppShortcut] { AppIntents.AppShortcut( intent: MyAppIntent(), phrases: ["Open \(.applicationName)"], shortTitle: "Title", systemImageName: "plus" ) } }

In my case I messed up my previews by deleting simulator folders from the filesystem without going through xcode. I fixed this by running: xcrun simctl --set previews delete all

same, try going directly to appstoreconnect.apple.com.

I've run into two workarounds that are not ideal but accomplish the goal. Sequence a long press gesture before the drag gesture. longPress.sequenced(before: drag) Add an empty onTapGesture *before* the drag gesture.

I'm running into the same problem. SwiftUI + DragGesture + global coordinate system + Catalyst + MacOS 11. Adding that this occurs with a custom view and not just a slider. The gesture seems to be canceled the moment the gesture.location crosses outside of the bounds of the gestured-item's parent view.