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.

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.

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

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

+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" ) } }

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.

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.

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.

Not fixed in RC unfortunately.

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.

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

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

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.

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.

Same here, I've received this rejection on several app submissions over the last few weeks. Resubmitting and crossing my fingers the view loads seems to be all that works. SubscriptionStoreView doesn't seem to timeout appropriately in a no-network situation. It'd be nice to be able to have control over prefetching the products before showing the view.