AppIntent with flexible return types

Question

Created 3w

Replies 1

Boosts 0

Participants 2

To support AppIntent in our app, we plan to follow the same approach as the “Get Details of Reminders” Shortcut Action in the Reminders app, as recommended in this WWDC session (https://developer.apple.com/wwdc24/10176?time=166). The goal is to allow querying all properties of an entity—referred to as “Node” in our app—using a single, configurable intent. For instance, we want one intent that can query properties like “Title,” “Background Color,” and “Font Name” for a specific node.

However, since the returned properties have varying data types, this setup requires flexible return types in the perform implementation of our “Get Details” intent. The challenge is that the AppIntent protocol mandates the use ReturnsValue one associated type as the result of perform. For example, we can use ReturnsValue<String> to retrieve the “Title” property, but this would restrict us from using ReturnsValue<Color> for the “Background Color” property.

What’s the best approach for implementing an Intent where the return types vary based on the input parameters provided?

Boost

Answer 1

DTS Engineer OP

Apple

2w

As you know, there's not a way for your intent to have multiple return types, so I'd appreciate if you could open an enhancement request using Feedback Assistant, so we can consider this idea in the future. Once you file the request, please post the FB number here.

What’s the best approach for implementing an Intent where the return types vary based on the input parameters provided?

There isn't an exact best practice I can provide for your needs. The video link you included uses an example based on defining multiple Open intents to different UI destinations in the app, so the UI destinations can all merge into a single Open intent with a parameter, without a return value. For your app, that might mean a single intent with a parameter — Get <Document Parameter> — but since that needs to return different types, it's not possible to implement the advice from that session of folding this into that single intent either.

While I can't provide a best practices path to follow for your needs in light of the API limits, I suggest considering the following questions for your app to help you identify the best path for your needs.

How will this intent be used in context? The nature of these document properties makes it seem like it would be best used in a configured shortcut to automate a task. Building on that idea, if I have the expected use right, is the data output by this intent being used as an input for use with another intent from your app? Is the output being used by an intent from another app? If you're looking to allow for a customer to write shortcuts for common actions over a document type that your app owns and that your app defines these actions as intents for, perhaps you can define a single intent whose output is your own app entity of document metadata that can represent all of the various data that could be returned from the app as input to another intent. If your app needs to work more with intents defined by other apps, can the data you return use the Transferable support that's new to iOS 18 to allow you to return a single type, but also allow the receiving app intent to chose a representation they can use?

Those questions and ideas are just meant to be starters and see where they lead for the types of uses you envision for your app. While your example took me to document-based workflows as examples, you may find that your needs lead you to completely different answers.

— Ed Ford,  DTS Engineer

0