Apple releases Siri: you no longer need your app to fit in a box.

Imagine your app can find a lesson, track a delivery or book a padel court. It does its job well. It has the data, the logic and an interface you've spent months working on. But ask Siri to do the same thing and, as far as the assistant is concerned, much of that work doesn't exist.

Not because the app can't do it. Because its functionality doesn't fit the boxes Apple had made for it.

That's the limit Apple is starting to remove with the Siri AI Developer Preview, announced on November 3 alongside the 27.3 betas. And “starting” matters: this is a developer preview, not a feature we can ship to all our users today.

With that distinction out of the way, the interesting part isn't the calendar. It's how app design changes when the interface no longer ends at the edge of a screen.

First, we had to fit the schema

Siri AI's third-party app integration relied on App Schemas: predefined actions grouped into thirteen domains, including mail, messages, photos, notes, calendar, audio and video. If your app fitted one of them, you could describe an action the system understood. Send a message. Play an audiobook. Create a note.

What if your app's defining feature was something else? Track a delivery, manage a gym membership, resume a lesson. That was where the map ended.

App Shortcuts let us offer actions to Siri, but we still depended on invocation phrases and on users knowing what to ask for and which app to use. Integration wasn't absent. There was simply a considerable gap between exposing a command and letting the assistant understand an intention.

With this preview, Apple is beginning to close that gap.

A small macro. A much bigger change

The iOS, iPadOS, macOS and visionOS 27.3 betas, together with Xcode 27.3, let any developer try this integration. There's no special program to join and no new entitlement to request for access to the preview.

We can turn a custom App Intent into a tool Siri chooses when handling a request. It doesn't have to fit an existing schema. We can also make our custom entities discoverable in Spotlight, while taking advantage of personal context, onscreen awareness and natural language.

The entry point is this macro: @AppIntent(.tool). It adds conformance to ToolIntent and makes the intent available as a tool. It doesn't magically give Siri control of the whole app: we expose the actions we choose to implement.

Here's an example from one of those apps that used to fall outside the map: a delivery tracker.

import AppIntents
@AppIntent(.tool)
struct CheckDeliveryStatus: AppIntent {
    static let title: LocalizedStringResource = "Check Delivery Status"
    static let description = IntentDescription(
        "Returns the current status and estimated arrival of one of the user's deliveries.",
        searchKeywords: ["package", "shipment", "tracking"]
    )
    @Parameter(
        title: "Delivery",
        description: "The delivery to check. Use the most recent active one if the user doesn't say which."
    )
    var delivery: DeliveryEntity
    func perform() async throws -> some IntentResult & ProvidesDialog {
        // DeliveryTracker is an actor in the app.
        let status = try await DeliveryTracker.shared.status(for: delivery.id)
        return .result(dialog: "\(delivery.name): \(status.summary)")
    }
}

The example leaves out the entities, their queries and the app's actor implementation. What matters here is the boundary: which action we offer and how we explain when the system should use it.

Look at the descriptions. We might once have treated them as secondary strings displayed in Shortcuts. Here they form part of our interface with the model. Siri uses them to understand what a tool does, distinguish it from other tools and resolve its parameters.

An ambiguous description is no longer just a copy problem. It can lead to the wrong action being selected. And writing “use the most recent delivery” doesn't implement that selection either: resolution and the necessary checks remain our app's responsibility.

One more detail: if an intent already adopts a Siri-compatible schema, don't add the macro automatically. Apple explicitly says not to. This isn't about scattering annotations across a project. It's about deciding what we expose.

Skills offer guidance. Code sets the boundaries

Some requests need more than one action. That's where app skills come in: instructions that help Siri understand how several tools fit together and what makes our domain different.

They live in one Skills.skillsbundle per target, with a folder for each skill and a SKILL.md inside it. If you work with coding agents, the format will look familiar: a subset of Agent Skills, with name and description in the frontmatter and a body limited to 10,000 characters. No scripts or supporting files. Siri considers the description first and only loads the body once it decides the skill is relevant.

---
name: delivery-issues
description: Helps the user resolve a late, missing or damaged delivery in DeliveryExample.
---
First, use the check delivery status tool to confirm where the package is.
If it's less than a day late, tell the user and offer to notify them on arrival.
Don't open a claim in that case. If it's missing or damaged, ask the user for a
short description and then use the open claim tool. Never use the cancel order
tool unless the user explicitly asks to cancel.

But Apple includes a warning worth reading twice: a skill can't enforce deterministic behavior. Siri doesn't necessarily execute the tools we list in the order we list them.

“Never cancel unless the user asks” helps guide the model. It doesn't replace a check in the cancellation tool. If an action requires confirmation, authentication or a business condition to be met, that requirement belongs in code.

It's the difference between giving someone a manual and putting a lock on a door. The manual explains when they may enter. The lock prevents them from entering when they shouldn't. We need both.

This is one of the judgments we'll work on in the upcoming Swift Agentic Program. The problem is the same whether the agent is Siri or it's writing code inside Xcode: understanding what we can delegate and what we must guarantee.

Be Native: the content was there. Siri needed a way in

In Be Native, our app for learning Apple development, this limitation isn't hypothetical. We know it. Siri AI can play our podcasts through the audio schema and create or look up notes through the notes schema. But much of the app's value sits outside those categories.

We have a bilingual semantic search engine built on on-device embeddings. Yet the action we can offer the system for finding content opens the app with the search already prepared. Siri doesn't return the lessons: it takes us to the door and leaves us to carry on.

Resuming the last lesson is similar. There's a shortcut, but users have to set it up and remember how to invoke it. The functionality exists. What's missing is a natural way for the system to discover and use it.

The preview lets us approach this differently. Lessons can be exposed as entities Siri finds in Spotlight. Resuming playback can be a tool. And a request such as “pick up where I left off in Be Native” can express what the user wants without making them learn a command name.

We can also imagine asking about this week's new content or our Swift concurrency lessons and getting results as cards, without opening the app first. That's something we need to implement and evaluate, not a feature we're announcing as already available in Be Native.

The distinction matters: we aren't making the app redundant. We're bringing its functionality to the place where the user needs it.

Architecture is an interface too

Apple gives a clear example. We request a ride, follow its arrival in a Live Activity and say, “change the pickup to a different address.” We don't have to name the app again if the context identifies it.

The preview supports leaving out the app's name while it's in the foreground, while it has an active Live Activity, or during a Siri conversation in which it has already been mentioned. In the background, outside those contexts, the request must name it. This isn't unrestricted access to arbitrary apps. It's context.

That means designing two layers. The visible one, with screens, buttons and navigation. And an invisible one: the actions the app can perform and the entities it can act on. Verbs and nouns, if you like. But properly defined.

If making a booking requires us to simulate seven taps inside a view, we have a problem. That operation needs to exist as logic we can call and check without relying on the visual journey. Not just for Siri. Separating responsibilities was already a good idea before the model arrived.

Results can appear in card snippets built with our own views and visual identity. And when a request spans several apps, entities need transferable representations the other app can understand. Exposing an action isn't enough if its data is still locked inside our private format.

Testing changes too. A model's output can vary between runs: checking a phrase once and calling it done doesn't prove much. Xcode's Siri Integration Advisor reviews our integration and suggests improvements; Siri Evaluations lets us script conversations and observe which intents, entities and skills Siri uses.

We need to repeat those evaluations, as Apple recommends. Tests for our logic still matter. Evaluations of the model's behavior matter too. Neither replaces the other.

What deserves to be within Siri's reach?

Apple already provides examples in fifteen of its apps: finding a café we visited, archiving old files, managing messages, building a playlist or creating an appointment. The question shouldn't be “can we add voice to this?” It should be “what does the user gain by expressing this intention without navigating our interface?”

Good places to start:

• Specific actions that make sense in one sentence: check, book, add, reorder, change or cancel with confirmation.
• Content we remember by context rather than by folder: “the one I saw on Tuesday.”
• Continuing an ongoing task, such as a ride, delivery or workout with a Live Activity.

Places to pause:

• Search tools that duplicate what Siri should resolve through Spotlight or our entity queries. For Be Native, exposing content and its queries isn't the same as indiscriminately adding an intent called “search.”
• Tasks that need visual precision or exploration: editing a photo pixel by pixel, browsing a catalog for pleasure or playing a game.
• Irreversible or high-impact actions without explicit confirmation in code.
• Sensitive data returned without reviewing its authentication policy.

That last point isn't an implementation detail. It's a product decision.

Exposing data doesn't mean showing everything

In Apple's banking example, the entity can be accessible while each property is treated differently: the nickname requires authentication, the balance requires local device authentication, and the routing number is marked as internal, out of reach of Siri and Shortcuts.

We can apply the same reasoning to a delivery:

struct DeliveryEntity: IndexedEntity {
    static let typeDisplayRepresentation: TypeDisplayRepresentation = "Delivery"
    static let defaultQuery = DeliveryQuery() // Omitted for brevity.
    let id: UUID
    @Property(title: "Item", description: "What the user ordered, as shown in the app.")
    var name: String
    @Property(
        title: "Delivery Address",
        description: "Where the package will be delivered.",
        authenticationPolicy: .requiresLocalDeviceAuthentication
    )
    var address: String
    @Property(title: "Carrier Token", visibility: .internal)
    var carrierToken: String
    var displayRepresentation: DisplayRepresentation {
        DisplayRepresentation(title: "\(name)")
    }
}

By default, entities don't require authentication before showing their information. And there's an important distinction: a property's policy applies to Siri's responses. If the intent itself returns sensitive information in its result, we must protect the intent too. Locking one door won't help if we leave another open.

Before turning old intents into tools, we should review what they return, who can execute them and what effects they produce. Designing these boundaries is another thread running through the Swift Agentic Program.

The 27.3 beta release notes also acknowledge an issue where Siri AI may display entities without requesting the unlock their policy requires. So use fictional data for these tests. A beta isn't the place to find out how much we trust the privacy of our real data.

We can start today. Shipping is another matter

The preview works with development-signed builds on compatible devices, or with internal TestFlight testers. It isn't available to external testers or App Store users, even if the integration is included in the binary. Skills can't be tested in the Simulator either.

Apple says App Store submissions will open in spring and describes customer availability as coming “in a few months.” That isn't a guaranteed general-release date. The APIs may change, and details of the terms and policies for these experiences are still to come.

There's another dependency to keep in mind: features that rely on server-side models, including Siri AI, have daily usage limits. Apple says expanded paid access will come in the future, but we shouldn't design a core feature around the assumption of an unlimited quota we don't control.

For those of us working from Spain, language support and availability are different questions. Siri AI supports English, Spanish, French, Japanese, Korean and Portuguese, but it remains unavailable on iPhone, iPad and Apple Watch in the European Union. It is available on Mac and Apple Vision Pro, subject to the relevant language, account and device requirements. For many of us, the test bench will be a Mac.

Is it worth starting before we can distribute it? Good entities, precise descriptions and logic separated from views aren't things we prepare the night before launch. Some of that work already improves our Spotlight and Shortcuts integration; what we can reuse in widgets will depend on the app.

The news isn't that Siri will press our buttons for us. It's that we can explain what our app can do and give Siri a safe way to do it.

And however capable the model on the other side becomes, that part is still our responsibility as developers.