Yes. The compiler is complaining because you haven't specified a title. struct SearchIntent: ShowInAppSearchResultsIntent { static let title: LocalizedStringResource = "Search App" static let searchScopes: [StringSearchScope] = [.general] static var openAppWhenRun: Bool = true @Parameter(title: "Search Text") var criteria: StringSearchCriteria @MainActor func perform() async throws -> some IntentResult { return .result() } } The above should compile for you. To find out how to conform to a protocol, ⌘ + click on the protocol (ShowInAppSearchResultsIntent) to see what is required in the docs.

Regarding static vs dynamic, are you simply referring to the Mach-O Type setting or are you referring to something else? I have the framework target set to Dynamic and compilation still fails. It should be set that way in the sample projected provided in FB14507102. Let me know if there's something else I'm missing here, but this seems like a bug.

This is still an issue as of Xcode 16.1 Beta 1.

This is still an issue as of Xcode 16.1 Beta.

I have filed an enhancement request per OP's forum post: FB14587703. We would love to see this supported by Controls.

Rico, I have a feedback out there with a sample project for an issue with app intents and controls where the app doesn't open despite openAppWhenRun = true. I think this might be related to OP's issue and recent regressions with AppIntent behavior. That feedback is FB14357691. Thank you!

It doesn't appear like this is supported at the moment, but would love to hear from Apple to learn more!

It appears this functionality is currently bugged or not implemented fully as of Xcode 16.0 Beta 4, but I have gotten to test my intent using the following method: In Shortcuts, create a new shortcut and then in the 'Search Actions' field, type "Search" Your app might show up there. Tap the result for your app icon, and you should be able to configure the intent and try out in app search for your app.

This is still an issue as of Xcode 16.0 beta 4. FB14507102

You call it like this somewhere in your perform method. @MainActor func perform() async throws -> some IntentResult & OpensIntent { guard let url = URL(string: "myapp://myappintent") else { // throw an error of your choice here } return .result(opensIntent: OpenURLIntent(deepLink)) } More here: https://stackoverflow.com/questions/78716058/ios-18-control-widget-that-opens-a-url

Can we get some clarification from an Apple engineer on what AppIntent result types are supported by Controls? It seems silly that we have access to so much from the AppIntents/AppShortcuts ecosystem which all compiles fine but fails silently when used with Controls. Dialogs and snippet views feel like things that should be supported. If they can't be used directly, we should at least be given the option to launch an existing AppShortcut that utilizes them. It seems like without putting the control intent and widget within both the extension and app target, and having the intent open the app, the point of the intent is pretty much useless. It's not clear to me, nor is it presently debuggable, what type of functionality can be run in a ControlConfigurationIntent at all. To answer your question it seems currently the only options are opening the app and showing an error message there, or briefly starting a live activity which might display an error message, and then invalidates itself after a set time interval. This seems like a ill-advised workaround though.

To see if you can get it working, try putting everything in the same file (ControlConfigurationIntent and your ControlWidget) and then make sure that file is added to your main app target as well as your extension or widget bundle. This most basic code below should work with any ControlWidgetButton and when tapped will open the app. struct SampleIntent: ControlConfigurationIntent { static var title: LocalizedStringResource = "Title" static var description = IntentDescription("Description.") /// Launch your app when the system triggers this intent. static let openAppWhenRun: Bool = true @MainActor func perform() async throws -> some IntentResult { // You can add more functionality here like a deep link into your app either using a result type that opens a url or write an extension that routes to a screen. return .result() } }

I have discovered a workaround here: https://developer.apple.com/forums/thread/758637 It would be nice if we could get an explanation or some diagnostics as to why we need to add our control widgets to the app itself, when they are supposed to reside in an extension or Widget Bundle, since in fact, the Xcode project / target creation tool will put the default Control in an extension target only causing the above code to not work.

I am experiencing this issue as well. It appears to happen if the Tip resides in a framework. Here's my own feedback: FB14037329

Try using .contentTransition(.identity). Does that help?