1. Escenario, objetivos y límites
Una aplicación de colaboración contiene proyectos, comentarios y tareas. Un usuario puede invocar "completar tarea", "compartir proyecto" o "eliminar comentario" a través de Siri, Spotlight, Shortcuts o Apple Intelligence. Cada punto de entrada debe preservar la misma autorización y resultado, y una tarea debe poder reanudarse en otro dispositivo.
Establece el límite primero: los App Intents son interfaces descubribles para acciones y entidades. No deben omitir la autorización, auditoría o transacciones existentes del servidor. Las sugerencias del sistema aumentan el alcance, pero no hacen que una invocación sea confiable; trata cada intent como una superficie de llamada pública.
2. El valor de producto de App Intents
El protocolo AppIntent de Apple hace que las acciones de la aplicación sean descubribles para Siri, Spotlight, Shortcuts y Apple Intelligence. Las actualizaciones de App Intents de junio de 2026 también describen esquemas de aplicaciones, identidad de entidad multidispositivo estable mediante SyncableEntity, confirmación de propiedad para acciones sensibles o destructivas mediante OwnershipProvidingEntity y IntentFile para recibir contenido suministrado por otras aplicaciones como parámetros.
Estas capacidades resuelven el descubrimiento y la interoperabilidad semántica. No deciden la autorización del negocio, el manejo de conflictos ni la política de deshacer. Separa "lo que el usuario quiere", "si el sistema puede realizarlo de forma segura" y "cómo se recupera el usuario ante un fallo".
3. Modelar acciones y entidades
Para cada intent, define entradas, visibilidad, condiciones previas, resultado y efectos secundarios. Un nombre para mostrar puede cambiar, pero el ID de negocio debe ser estable, verificable y estar vinculado al usuario y tenant actuales. No utilices la posición en una lista, el título o una clave de base de datos local como identidad multidispositivo.
struct CompleteTaskIntent: AppIntent {
static var title: LocalizedStringResource = "Complete task"
@Parameter(title: "Task")
var task: TaskEntity
func perform() async throws -> some IntentResult {
try await TaskService.complete(taskID: task.id)
return .result()
}
}Si la resolución de la entidad falla, los permisos cambiaron o las versiones son incompatibles, devuelve una opción comprensible o una ruta de inicio de sesión. Nunca adivines un proyecto similar para ejecutarlo.
4. Diseñar una identidad multidispositivo estable
Si una tarea puede continuar en múltiples dispositivos, su entidad debe exponer una semántica de identidad estable, y el servidor debe garantizar que el mismo ID de entidad haga referencia al mismo recurso en cada dispositivo. La capa de sincronización aún maneja eliminaciones, archivado, traslados de tenant y cachés sin conexión obsoletas; la resolución vuelve a verificar que el usuario actual pueda acceder al recurso.
No trates SyncableEntity como una base de datos de sincronización. Este expresa que la identidad puede permanecer estable en todos los dispositivos; la sincronización de datos, la resolución de conflictos y el deshacer siguen siendo responsabilidades del backend. Mantén mapeos de alias y registros de auditoría a través de fusiones o migraciones para que un Shortcut antiguo no apunte a la entidad incorrecta.
5. Confirmar acciones sensibles y propiedad
Eliminar, compartir públicamente o transferir acceso debe confirmar que el usuario es propietario de la entidad o tiene el permiso de operación requerido. Utiliza OwnershipProvidingEntity para expresar la propiedad y haz que la confirmación explique el objeto, el impacto y la reversibilidad. Vincula la confirmación a la solicitud, el usuario y la versión del recurso actuales en lugar de reutilizar una confirmación antigua.
Para entidades públicas o pertenecientes a un equipo, el servidor debe devolver la decisión de propiedad; la caché local no es suficiente. Mantén acotadas las preferencias de "no volver a preguntar" y conserva la confirmación y la auditoría para acciones de alto riesgo.
6. Autorización, idempotencia y efectos secundarios
El sistema puede reintentar un intent, y un Shortcut puede ejecutarse dos veces. Cada intent que cambie el estado debe llevar una clave de idempotencia y una versión del recurso. Después de la autorización, el servidor realiza una actualización condicional y devuelve el mismo resultado de negocio para una solicitud duplicada. Las acciones de solo lectura pueden ser más rápidas, pero aun así deben aplicar la visibilidad.
No codifiques permisos en parámetros de lenguaje natural. Vuelve a autorizar a partir de la sesión, el tenant, la propiedad de la entidad y la versión actual, y registra el punto de entrada (Siri, Spotlight, Shortcuts o la aplicación), el dispositivo emisor y el resultado. Distingue en la respuesta entre inicio de sesión caducado, acceso prohibido, entidad modificada y fallo temporal del servicio.
7. Descubrimiento, observabilidad y recuperación
Elige esquemas de aplicación y acciones descubribles en función del valor para el usuario en lugar de exponer cada API interna. Para cada intent, mide el éxito de la resolución, la denegación de autorización, el abandono de confirmaciones, la ejecución duplicada, la recuperación multidispositivo y la tasa de finalización. Compara los puntos de entrada por conversión, no solo por el recuento de invocaciones.
Muestra un resumen antes de la ejecución y un resultado con una ruta para deshacer después. Ante una interrupción de red, persiste un estado de solicitud reintentable, pero nunca repitas indefinidamente una acción destructiva en segundo plano. Si la entidad se elimina o su versión entra en conflicto, devuelve alternativas y una ruta de intervención humana mientras conservas un evento de auditoría.
8. Rúbrica y preguntas de seguimiento
Puntos que se deben explicar
- Tratar los App Intents como interfaces públicas de producto que aún requieren autorización en el servidor, auditoría, idempotencia y verificaciones de versión.
- Distinguir la identidad de entidad estable de la sincronización de datos real, incluidas eliminaciones, migraciones, estados sin conexión y conflictos.
- Diseñar confirmación de propiedad, preferencias de omisión de confirmación con alcance acotado, reversión y recuperación ante fallos para acciones sensibles.
Preguntas de seguimiento
- Un usuario confirma la eliminación en un teléfono y luego un Shortcut sin conexión en una tableta la vuelve a ejecutar. ¿Cómo garantiza el servidor un resultado consistente?
- Un proyecto de equipo compartido no tiene un único propietario. ¿Quién puede confirmar una transferencia de permisos?
- ¿Cómo decides que un intent merece sugerencias del sistema en lugar de agregar acciones ruidosas y de bajo valor?
Guía de evaluación
Una respuesta excelente conecta el descubrimiento, la identidad, la autorización, la confirmación, la idempotencia y la recuperación en una sola cadena de producto: los puntos de entrada del sistema expresan la intención, el servidor toma la decisión final y el usuario puede entender el impacto y continuar tras un fallo.