# Apple libera Siri: ya no necesitas que tu app encaje en una casilla.

Imaginad que vuestra app sabe encontrar una lección, seguir un envío o reservar una pista de pádel. Lo hace bien. Tiene sus datos, su lógica y una interfaz en la que habéis trabajado durante meses. Pero le pedís a Siri que lo haga y, para el asistente, buena parte de ese trabajo no existe.

No porque la app no pueda hacerlo. Porque su funcionalidad no cabe en las casillas que Apple había previsto para ella.

Ese es el límite que empieza a caer con la Siri AI Developer Preview, anunciada el 3 de noviembre con las betas 27.3. Y digo «empieza» por algo: estamos ante una preview para desarrolladores, no ante una función que podamos publicar hoy para todos nuestros usuarios.

Aclarado eso, lo interesante no está en el calendario. Está en cómo cambia nuestra forma de diseñar una app cuando la interfaz deja de terminar en sus pantallas.

## Antes teníamos que encajar en el esquema

La integración de Siri AI con apps de terceros se apoyaba en los App Schemas: acciones predefinidas, agrupadas en trece dominios como correo, mensajes, fotos, notas, calendario, audio o vídeo. Si vuestra app encajaba ahí, podíais describir una acción que el sistema entendiera. Enviar un mensaje, reproducir un audiolibro, crear una nota.

¿Y si lo que hacía especial a vuestra app era otra cosa? Seguir un envío, gestionar una cuota del gimnasio, retomar una lección. Ahí se acababa el mapa.

Los App Shortcuts permitían ofrecer acciones a Siri, pero seguíamos dependiendo de frases de invocación y de que el usuario supiera qué pedir y en qué app. No es que no hubiera integración. Es que había una distancia importante entre exponer un comando y dejar que el asistente comprendiera una intención.

Con la nueva preview, Apple empieza a cerrar esa distancia.

## Una macro pequeña. Un cambio bastante mayor

Las betas de iOS, iPadOS, macOS y visionOS 27.3, junto con Xcode 27.3, permiten que cualquier desarrollador pruebe esta integración. No hay que entrar en un programa especial ni solicitar un entitlement nuevo para acceder a la preview.

Podemos convertir un App Intent propio en una herramienta que Siri elija al resolver una petición. No tiene que encajar en uno de los esquemas existentes. Y podemos hacer que Siri encuentre nuestras entidades personalizadas en Spotlight, además de aprovechar el contexto personal, el contenido de la pantalla y el lenguaje natural.

El punto de entrada es esta macro: `@AppIntent(.tool)`. Añade la conformidad a `ToolIntent` y hace que el intent esté disponible como herramienta. No convierte toda la app en algo que Siri pueda manejar por arte de magia: exponemos las acciones que decidamos implementar.

Veamos un ejemplo con una de esas apps que se quedaban fuera: un gestor de envíos.

```swift
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 es un actor de la app.
        let status = try await DeliveryTracker.shared.status(for: delivery.id)
        return .result(dialog: "\(delivery.name): \(status.summary)")
    }
}
```

El ejemplo omite la implementación de las entidades, sus consultas y el actor de la app. Nos interesa la frontera: qué acción ofrecemos y cómo explicamos al sistema que debe usarla.

Fijaos en las descripciones. Hasta ahora podíamos tratarlas como textos secundarios que aparecían en Atajos. Aquí forman parte de la interfaz con el modelo. Siri las usa para entender qué hace una herramienta, distinguirla de otras y resolver sus parámetros.

Una descripción ambigua deja de ser solo un problema de redacción. Puede convertirse en una acción mal elegida. Y escribir «usa el envío más reciente» tampoco implementa esa selección: la resolución y las comprobaciones necesarias siguen siendo responsabilidad de nuestra app.

Por cierto: si un intent ya adopta un esquema compatible con Siri, no hay que añadirle la macro por sistema. Apple lo indica expresamente. No se trata de espolvorear anotaciones sobre el proyecto, sino de decidir qué estamos exponiendo.

## Las skills orientan. El código pone los límites

Hay peticiones que no se resuelven con una sola acción. Para esos casos llegan las app skills: instrucciones que ayudan a Siri a entender cómo se relacionan varias herramientas y qué particularidades tiene nuestro dominio.

Se añaden en un `Skills.skillsbundle` por target, con una carpeta por skill y un `SKILL.md` dentro. El formato os sonará si trabajáis con agentes de programación: es un subconjunto de Agent Skills, con `name` y `description` en el frontmatter y un cuerpo de hasta 10.000 caracteres. Sin scripts ni archivos de apoyo. Siri considera primero la descripción y solo carga el cuerpo cuando entiende que la skill es pertinente.

```markdown
---
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.
```

Ahora bien, Apple hace una advertencia que conviene leer dos veces: una skill no impone comportamiento determinista. Siri no ejecuta necesariamente, en orden, la lista de herramientas que escribamos.

Ese «nunca canceles sin que el usuario lo pida» ayuda a orientar al modelo. No sustituye una comprobación en la herramienta que cancela. Si una acción necesita confirmación, autenticación o una condición de negocio, esa condición tiene que estar en código.

Es la diferencia entre darle un manual a alguien y poner un cierre en una puerta. El manual explica cuándo se puede entrar. El cierre impide que se entre cuando no se debe. Necesitamos ambos.

Este es uno de los criterios que trabajaremos en el próximo Swift Agentic Program. El problema es el mismo si el agente se llama Siri o si está escribiendo código dentro de Xcode: entender qué podemos delegar y qué debemos garantizar.

![Siri ahora no está limitado y puede encontrar cualquier contenido sin problema](https://image.service.eu.axinom.net/transform/72a20w8irkd812lj5hqycl0ft-3dl5y1dj0seejmhh8wynzscv2/PmRVDjBPUJqCasoi9bTnJK.png)

## Be Native: el contenido estaba. A Siri le faltaba una puerta

En Be Native, nuestra app para aprender desarrollo Apple, esta limitación no es una hipótesis. La conocemos. Siri AI puede reproducir nuestros podcasts mediante el esquema de audio y crear o consultar notas mediante el de notas. Pero buena parte del valor de la app queda fuera.

Tenemos un buscador semántico bilingüe, con embeddings en el dispositivo. Sin embargo, la acción que podemos ofrecer al sistema para buscar contenido abre la app con la búsqueda ya preparada. Siri no devuelve las lecciones: nos lleva hasta la puerta y nos deja seguir a nosotros.

Algo parecido ocurre al retomar la última lección. Hay un atajo, pero el usuario tiene que configurarlo y recordar cómo invocarlo. La funcionalidad existe. Lo que falta es que el sistema pueda descubrirla y utilizarla con naturalidad.

La preview nos permite plantearlo de otra forma. Las lecciones pueden exponerse como entidades que Siri encuentre en Spotlight. Retomar la reproducción puede ser una herramienta. Y una petición como «sigue por donde lo dejé en Be Native» puede expresar lo que el usuario quiere, sin obligarlo a aprender el nombre de un comando.

También podemos imaginar una consulta sobre el contenido nuevo de la semana o sobre nuestras lecciones de concurrencia en Swift, con resultados en tarjetas, sin abrir primero la app. Eso es una posibilidad que debemos implementar y evaluar, no algo que estemos anunciando ya como disponible en Be Native.

La diferencia importa: no estamos haciendo que la app sobre. Estamos llevando su funcionalidad al lugar desde el que el usuario la necesita.

## La arquitectura también es interfaz

Apple pone un ejemplo muy claro. Pedimos un coche, seguimos su llegada en una Live Activity y decimos: «cambia la recogida a otra dirección». No hace falta volver a mencionar la app si el contexto permite identificarla.

La preview contempla esa omisión del nombre mientras la app está en primer plano, tiene una Live Activity activa o forma parte de una conversación de Siri en la que ya se ha mencionado. En segundo plano, fuera de esos contextos, la petición debe nombrarla. No es acceso indiscriminado a cualquier app. Es contexto.

Eso nos obliga a diseñar dos capas. La visible, con pantallas, botones y navegación. Y otra que no se ve: las acciones que la app sabe ejecutar y las entidades sobre las que puede hacerlo. Verbos y sustantivos, si queréis. Pero bien definidos.

Si para reservar algo necesitamos simular siete pulsaciones dentro de una vista, tenemos un problema. Esa operación debe existir como lógica que podamos llamar y comprobar sin depender del recorrido visual. No por Siri solamente. Porque separar responsabilidades ya era una buena idea antes de que llegara el modelo.

Los resultados pueden mostrarse en card snippets construidos con nuestras vistas y nuestra identidad visual. Y, cuando una petición cruza varias apps, las entidades necesitan representaciones transferibles que la otra app pueda entender. Exponer una acción no basta si sus datos siguen encerrados en nuestro formato privado.

También cambia cómo probamos. El resultado de un modelo puede variar entre ejecuciones: comprobar una frase una vez y darla por buena no demuestra demasiado. El Siri Integration Advisor de Xcode revisa nuestra integración y propone mejoras; Siri Evaluations permite guionizar conversaciones y observar qué intents, entidades y skills utiliza Siri.

Hay que repetir esas evaluaciones, como recomienda Apple. Las pruebas de nuestra lógica siguen haciendo falta. Las evaluaciones del comportamiento del modelo, también. Una no sustituye a la otra.

## Qué merece estar al alcance de Siri

Apple ya ofrece ejemplos en quince de sus apps: localizar una cafetería visitada, archivar archivos antiguos, gestionar mensajes, preparar una lista de reproducción o crear una cita. El criterio no debería ser «¿podemos ponerle voz?», sino «¿qué gana el usuario al expresar esta intención sin recorrer nuestra interfaz?».

Tiene sentido empezar por:

- Acciones concretas que se entiendan en una frase: consultar, reservar, añadir, repetir un pedido, cambiar o cancelar con confirmación.
- Contenido que recordamos por su contexto, no por su carpeta: «el que vi el martes».
- La continuación de una tarea en marcha, como un trayecto, un envío o un entrenamiento con Live Activity.

En cambio, conviene frenar antes de:

- Crear herramientas de búsqueda que dupliquen lo que Siri debe resolver mediante Spotlight o las consultas de nuestras entidades. En el caso de Be Native, exponer el contenido y sus consultas no es lo mismo que añadir indiscriminadamente un intent llamado «buscar».
- Llevar a la voz tareas que requieren precisión visual o exploración: retocar una foto píxel a píxel, recorrer un catálogo por gusto o jugar.
- Ofrecer acciones irreversibles o de alto impacto sin confirmación explícita en código.
- Devolver datos sensibles sin revisar su política de autenticación.

Este último punto no es un detalle de implementación. Es una decisión de producto.

![Hay que tener un criterio claro de qué queremos exponer y qué no a Siri](https://image.service.eu.axinom.net/transform/72a20w8irkd812lj5hqycl0ft-3dl5y1dj0seejmhh8wynzscv2/AWmcJY3RqGyjSmHps51zRX.png)

## Exponer no significa enseñarlo todo

En el ejemplo bancario de Apple, la entidad puede ser accesible, pero cada propiedad tiene un tratamiento distinto: el alias requiere autenticación, el saldo exige autenticación local del dispositivo y el identificador de enrutamiento bancario queda marcado como interno, fuera del acceso de Siri y Atajos.

Podemos aplicar el mismo criterio a un envío:

```swift
struct DeliveryEntity: IndexedEntity {
    static let typeDisplayRepresentation: TypeDisplayRepresentation = "Delivery"
    static let defaultQuery = DeliveryQuery() // Omitida por brevedad.

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

Por defecto, las entidades no exigen autenticación para mostrar su información. Y hay un matiz importante: la política de una propiedad se aplica a las respuestas que ofrece Siri. Si el propio intent devuelve información sensible en su resultado, también debemos proteger el intent. No basta con cerrar una puerta si dejamos otra abierta.

Antes de convertir en herramientas intents antiguos, revisemos qué devuelven, quién puede ejecutarlos y qué efectos producen. Este diseño de límites es otro de los hilos del Swift Agentic Program.

Además, las notas de la beta 27.3 reconocen un problema por el que Siri AI podría mostrar entidades sin solicitar el desbloqueo que exige su política. Así que, para estas pruebas, datos ficticios. Una beta no es un lugar en el que comprobar cuánto confiamos en la privacidad de nuestros datos reales.

## Podemos empezar hoy. Publicarlo es otra historia

La preview funciona con builds firmadas en desarrollo, en dispositivos compatibles, o con testers internos de TestFlight. No está disponible para testers externos ni para quienes descarguen la app del App Store, aunque la integración vaya incluida en el binario. Las skills tampoco pueden probarse en el simulador.

Apple sitúa la apertura de envíos al App Store en primavera y habla de la llegada a clientes «en unos meses». No es una fecha de disponibilidad general garantizada. Las APIs pueden cambiar y faltan detalles sobre los términos y las políticas de estas experiencias.

Hay otra dependencia que conviene tener presente: las funciones que usan modelos de servidor, incluida Siri AI, tienen límites diarios. Apple anuncia acceso ampliado de pago en el futuro, pero no deberíamos diseñar una función esencial suponiendo una cuota ilimitada que no controlamos.

Y, si trabajamos desde España, hay una diferencia entre idioma y disponibilidad. Siri AI admite inglés, español, francés, japonés, coreano y portugués, pero sigue sin estar disponible en iPhone, iPad y Apple Watch dentro de la Unión Europea. En Mac y Apple Vision Pro sí, con los requisitos de idioma, cuenta y dispositivo correspondientes. Para muchos de nosotros, el banco de pruebas será el Mac.

¿Compensa empezar antes de poder distribuirlo? Unas buenas entidades, unas descripciones precisas y una lógica separada de las vistas no se preparan la víspera del lanzamiento. Además, parte de ese trabajo ya mejora nuestra integración con Spotlight y Atajos; lo que reutilicemos en widgets dependerá de nuestra app.

La novedad no es que Siri vaya a pulsar nuestros botones por nosotros. Es que podemos explicarle qué sabe hacer nuestra app y darle una forma segura de hacerlo.

Y esa parte, por mucho modelo que haya al otro lado, nos sigue correspondiendo a quienes la desarrollamos.