Validate your App Intents adoption with AppIntentsTesting

Hi. I am Venkatesh, a Software Engineer on the App Intents team. Today I'm going to show you how to test your App Intents with a brand new framework called AppIntentsTesting. The App Intents framework is a core part of how your app integrates with the system. And every year, it powers more experiences, for example, App Intents enables people to interact with their apps using Siri. It enables people to use the Shortcuts app to build powerful automations.

Spotlight uses it to surface your app's contents in system-wide search. Widgets use it to display your data on the Home Screen.

If you are new to AppIntents, check out this talk from WWDC25. And if you want to learn about new advances, check out this talk from WWDC26. With App Intents powering so many experiences, every intent, entity, and query needs to work correctly. AppIntentsTesting is a brand new framework that lets you test all of that, and more. Here is what we will cover today. First, I will introduce the sample app, and show you how to write your first test. Next, we'll look at how AppIntentsTesting runs your tests.

We'll then level up, by testing entity queries, and combining multiple intents.

And finally, we'll test some parts of App Intents that reach beyond your app; Spotlight and view annotations I'll now dive right in and show you how easy it is to get started with AppIntentsTesting. This is CometCal, a sample calendar app. It's a SwiftUI app that manages calendars, events, and attendees, and it fully integrates with App Intents. My colleague Justin and I have been working on it to make it easier for our crew of space adventurers to manage our missions. In this session, we'll learn how to test it, using AppIntentsTesting.

To learn about how we made CometCal available to Siri, check out his code-along.

I'll start off by writing a simple test that exercises the Create Calendar flow.

All I need to get started with AppIntentsTesting is a UI Testing bundle. I don't have one yet, so let me create one.

Let me give it a descriptive name. Next, I pick a development team. AppIntentsTesting requires the test runner and the app to use the same development team for code signing, so I'll make sure to pick the correct Team here. Next, I'll put in a Bundle Identifier.

And select the correct Target. Click Finish.

This creates my UI testing bundle for me. Let me create a new file for all my tests related to intent execution.

Great, I am now ready to start writing some tests.

Let me navigate to the intent I'm testing.

CreateCalendar creates a new calendar with a name, and color.

To begin, I need to import the AppIntentsTesting framework.

I start with a standard XCTestCase and create a test method.

I start the testing flow by creating an IntentDefinitions object.

IntentDefinitions takes in the CometCal bundle identifier, and gives me access to every intent, entity, and query the app defines without importing the app. To access the definition of a particular intent, I can use the intents property and pass in the Intent name as a subscript.

This gives me an IntentDefinition object. I can call makeIntent on it, to create a populated instance of the Intent.

I can pass in any parameters the intent expects.

Here, CreateCalendarIntent takes in a name and a color. I am in charge of a critical mission for humanity, and I need a descriptive name so my crew and I can fulfill this mission.

I'll call it Occupy Saturn. And give it a color. I'll make it red.

Here, color is an AppEnum. All I need to do is pass in the AppEnum's raw string value, and the framework converts it to the correct type. The test code doesn't build against your app, therefore the parameter names and types do not offer auto-completion. I need to make sure to fill them out correctly based on the intent parameters. This type conversion works out of the box with most parameter types. However, if you want to pass in your own custom types, look up IntentValueConvertibleWrapper in the documentation. Now that I created the intent, I call the .run() method to execute it in app.

If I need the return value from an intent's perform method, I can capture the result of the run method, and use the value property to get it.

Here, CreateCalendarIntent returns the new calendar as a CalendarEntity.

This is CalendarEntity.

It has a title property that we can check.

So, if I want to assert that the new event has the correct title, I first access the new calendar using result.value, and simply chain the required property name to it. This uses dynamic member lookup to get the title from the new calendar.

I am now ready to run this test. But before I do so, let me switch over to my phone, and check out which calendars I currently have.

The app currently has three calendars: Deep Space, Mission Control, and Stargazing. After I run the test, I expect the Occupy Saturn calendar to be added to the list. Let me switch back to Xcode, and run this test.

The test succeeded.

Let me check the phone to confirm that the new calendar exists. Yup, the test created the Occupy Saturn calendar with the color red.

All it took was five lines of code, and I executed an on-device App Intent using a test. Now that you've seen AppIntentsTesting in action, I'll talk about it in more detail.

AppIntentsTesting is an integration testing framework for your App Intents. Similar to UI tests, it uses strings to find your intents, without any access to the app's internals.

Your tests live in a standard XCUITest bundle, running in their own process. Your app runs in a separate process, and executes AppIntents on-device.

The test runner executes your App Intents across process boundaries. And receives execution results, without sharing any state.

Here's what AppIntentsTesting means for you as a developer. Your tests run through the full App Intents stack; the same code path people hit. No mocks, no stubs. Create an XCUITest bundle, or add it to your existing XCUI tests. Your Continuous Integration pipeline picks it up automatically. Structure your app code any way you want. Your test target never imports any code from your application- you only pass a bundle identifier. That means you don't need to compile your app code into your testing target.

All this gives you stable tests across releases. They don't depend on any UI. Not your app's. Not your system's.

With that overview in mind, I'll move on to some more involved tests. Your app's actions, data and queries are the building blocks of your App Intents integration. They power Shortcuts, Siri interactions, and Spotlight search. When this code regresses, it can often lead to people experiencing unexpected system behaviors.

Whenever your entities are looked up- in Shortcuts, through Siri, or anywhere else App Intents surfaces them- your entity queries are responsible for returning the right results. AppIntentsTesting helps you verify that behavior for string queries, identifier lookups, and suggested entities. Here's the situation. I have a mostly harmless device called a cosmic ray. Due to an unfortunate incident, I need to rename the Cosmic Ray Calibration event to Cosmic Ray Rebuilding. In fact, it's been happening so often, I should probably create a Shortcut for it.

The event already exists in the app. So I go to the Shortcuts app, go to my Shortcut, and search for the event. Initially, it shows a list of suggested events. If I want to search for some other events, I can use the search bar which calls EventEntity's string query to determine the results.

No Options Available; the string query isn't implemented yet. I'll use AppIntentsTesting to implement this with a test-driven approach.

Here's my test. I start off by creating the entity and intent definitions.

I want to ensure that the app contains a known set of events, so I run SeedSampleEventsIntent. This resets app data, and adds events. I will come back to this shortly. Ideally, I'd lift the Entity and Intent definitions out of the test function so other tests can reuse them, and move the data seeding to the setUp method. Let me do that. Going forward, I focus purely on test functionality.

Here is the updated test. I call the Entity string query using the entities(matching:) method on the Event entity definition. This executes the string query on-device. The method returns an array of EventEntity representations, so you can assert on the count.

Similar to intents, I can use dynamic member lookup to get the value of any entity property. Here, I am getting the title of the event, and asserting on it to confirm that the query works correctly. I'll run the test. And it fails, just as expected. The failure tells me exactly what I need to build.

Now I navigate to the EventEntityQuery. Currently, it can return events by identifier, and return suggested events. However, it has no EntityStringQuery capability. Let me add one.

I'll add an EntityStringQuery conformance and implement the entities(matching:) method. Filter events by title and return the matched EventEntities.

Now I go back to the test and run it, and it passes. I have confirmed that the Entity string query works as expected.

Now, I verify the changes on device. First, I make sure the event exists. Next, I go to the Shortcuts app, open my Shortcut, and search for the same event again. This time, it finds the event.

I wrote the test first, then built the feature to make it pass. That's test-driven development with AppIntentsTesting. Now, it's time to rebuild that Cosmic Ray! Time to level up, by combining multiple intents in one test. Often, to build complex Shortcuts, people take the results of an intent, and pass it as a parameter into another. This flow forms the basis of many useful automations. Here's the situation; I had set up a practice session for my team to get good at Asteroid Dodgeball. However, one of our teammates is new, so I ended up changing the purpose of the Event to go over the rules instead. Since this is a core workflow of the app, I want to write a test to simulate it.

This test builds on our previous examples. Let me walk you through it.

Start off by running CreateEventIntent with the required parameters. I've gone through how makeIntent handles type conversion in the previous examples.

The first three parameters all take primitive types. The last one is more interesting. The calendar parameter takes a CalendarEntity. However, I just pass in a string. The AppIntents runtime automatically calls the EntityStringQuery associated with the CalendarEntity and fills in the first matching value.

After creating the event, I check the title just to make sure.

Next, I run UpdateEventIntent. This takes in an event, and any updates I want to make. Since I am just updating the title, I pass that in. For the event to update, I can directly send in the EventEntity from the original run method. This mirrors how people compose intents in Shortcuts.

And finally, I assert that the event has the updated title.

This time, during test setup, I am launching the app, just so I can confirm it's working correctly. Time to run the test. The app launches, the event is created, and then updated.

Boom! Entity creation, chaining, update, and assertion; all on device, in a single test. Now where did I keep my rulebook for Asteroid Dodgeball … AppIntentsTesting tests are lightweight, fast and can run on every commit. For the test results to be reliable, each test needs to be self-contained. Test-Only intents help with that.

Test-only intents are simple, focused intents that only exist to help your tests. You can use them to improve test functionality. You can create exactly the data your tests need. No leftover data from previous runs causing flaky results.

You can jump directly to any view in your app without UI navigation. If you redesign a screen, these tests still work. And here's the broader idea; test-only intents can wrap any functionality in your app, even things you haven't adopted App Intents for yet. Internal navigation, data management, state manipulation- wrap it in a test-only intent, and you can test it through AppIntentsTesting. CometCal's source code includes a number of test-only intents. One example is SeedSampleEventsIntent from the earlier string query test. It creates a known set of events in your calendar. Here's how you can make any intent a test-only intent.

Mark it with isDiscoverable: false. This prevents the system from exposing it anywhere else.

And Wrap it in #if DEBUG compiler directive so only your tests can access this intent.

Up to this point, you've learned how to test your App Intents in isolation. The real power, though, is how App Intents lets your features reach people across the system, so they can use your app's functionality outside your app. I'll now show you how to test those system-level integrations.

Spotlight lets people search across the entire system from one place. When you index your entities, they show up right in those results, so people can find your app's content without needing to open the app first. When CometCal creates an event, it should index the entity in Spotlight. However, I once got an urgent transmission from my fleet commander asking me when the Dark Matter Symposium was. I know that nanoseconds are precious, so I wanted to use Spotlight to get this information and reply pronto. However, the Spotlight search surfaced nothing. This information on Dark Matter is fascinating, but not what I'm looking for! I went to the app, and the event did indeed exist. I quickly sent them the details, and got to work debugging.

I navigated to the event creation code to debug. The bug is simple; during development, I commented out the indexing code and never re-enabled it. The app's behavior didn't change, so the bug went undetected.

And the fix is simple, just uncomment the indexing call.

But how to make sure this never happens again? I can write a test, not to find the bug, but to prevent a regression.

I start by using the spotlightQuery() method to talk to Spotlight. This method takes a string, and returns a list of spotlight indexed EventEntity representations matching it. Initially, the event does not exist, so I ensure that spotlightQuery() returns no results.

Next, I use CreateEventIntent to create an event, exactly the same as before.

Once created, I expect the event to exist in the Spotlight index, so I query for it again. I assert that there is exactly one result, and the title matches. Now I run the test… And it passes. This test can now run on every commit. So if the Spotlight integration ever breaks again, this test will catch it immediately.

Now, to perform a quick check to confirm that the event is indeed indexed in Spotlight. Great! Now, my fleet commander gets their answer at the speed of Spotlight! View annotations tell the system which entity your view is currently showing, so Siri can understand what's on screen and act on it directly. CometCal tells Siri which EventEntity is on screen every time you navigate to an event. So, if I am viewing an event, and an unexpected wormhole jump yanks the phone from my hands, I can always call out and say: "Siri. What time is this event?".

Ideally, the view annotation tells Siri exactly which event is on screen, and Siri answers right away. But if that annotation is broken, Siri has no idea what's on screen.

Now, inter-dimensional travel happens to me more often than I'd like to admit, so I really need this feature working. Let me fix the the bug with the help of AppIntentsTesting.

I start off by navigating to the event page of an event using OpenEventIntent.

Because this test exists in an XCUITest bundle, I can use XCUI Automation to confirm that the app indeed renders the correct event on the screen.

I can then call the viewAnnotations() method on the Event entity. This method retrieves the list of EventEntity view annotations the system reports as currently on screen.

Now for the assertions. First, since only one event is on screen, I assert that the system returns only one ViewAnnotation object.

Then I assert that the Event entity is correct based on the title.

A ViewAnnotation object has an entity property that holds the actual entity representation. So, I can use dynamic member lookup to assert on specific properties such as title. Now I run the test. And it fails.

Then, I navigate to the EventDetailView to find out why. The issue is with the EntityIdentifier. I accidentally passed the event's calendar id as the identifier.

The fix is simple; I change it to the event's id.

Now I rerun the test. And this time it passes.

So now, the next time inter-dimensional travel catches me off-guard, I can say "Siri. When is this event?", and get the correct response. I can even follow up with "Where is it?", and Siri responds with the location.

I've covered a lot today. Now, take a step back and look at how AppIntentsTesting can augment your App Intents development workflow.

Start your AppIntents journey by implementing the fundamental types. These are your app's actions, data and queries. Now with AppIntentsTesting, you verify the foundational behavior of these types.

These tests act as unit tests for your App Intents integration.

Once the fundamentals are tested, integrate your app more deeply with the system. Annotate your views with entities, donate to Spotlight and pass data between apps. AppIntentsTesting lets you cover these integrations too, validating your app's experiences across the many ways people use it.

These can be your App Intents integration tests. With coverage at every layer, your app is ready to unlock some truly powerful experiences. At this stage, be sure to test your intents manually with Siri and the Shortcuts app to experience them just the way people would. That's AppIntentsTesting. A single framework that lets you test your intents, entities, enums, queries, and system integrations- all out-of-process, all automated.

Download the CometCal sample project to try it yourself, and explore the complete set of tests for the app.

This talk only scratches the surface of what AppIntentsTesting can do. Check out the documentation for the full API reference. And if you want to learn how to build Siri experiences with App Intents, check out this talk. Now you are ready to go and build something that is out of this world! Thanks for watching!