Tenemos una API REST. Apple tiene Shortcuts, una app de automatización que puede enviar solicitudes HTTP. Conectar una con la otra parecía un win gratis: “Hey Siri, publica esto” → POST a nuestra API → listo. Sin backend, sin OAuth, sin app que instalar.

Funciona. Está en mi teléfono. Lo que no pude hacer — y aquí es donde se pone interesante — fue construir, editar, versionar y distribuir ese shortcut desde código. Estas son las paredes contra las que choqué, con los errores exactos, para que puedas decidir si vale la pena invertir una tarde como la que yo invertí.

Lo que funciona

El shortcut en sí es trivial, tres pasos:

  1. Pedir entrada (texto) → “¿Qué vamos a publicar?”
  2. Obtener contenido de URL → POST a https://api.ejemplo.com/api/v1/create-post
  3. Cuerpo de la solicitud (JSON): content del paso 1, platforms como un array con un ID de conexión

Lo ejecutas, Siri pregunta, dictas, el post sale. Aquí el equivalente en curl para mostrar qué poca lógica tiene:

curl -X POST https://api.ejemplo.com/api/v1/create-post \
  -H "x-api-key: TU_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"content":"Publicado desde Siri","platforms":["linkedin-ABC123"]}'

Si omites scheduledTime el post se crea como borrador, que es justo lo que quieres mientras pruebas: nada sale a una audiencia en vivo.

Construirlo en el teléfono tomó unos cuarenta minutos, la mayoría buscando las acciones correctas en una interfaz localizada. Construirlo desde código tomó una eternidad. Aquí está el porqué.

Muro 1: no puedes escribir un archivo .shortcut a mano

Un shortcut en disco es una property list: WFWorkflowActions es un array de diccionarios, cada uno con un identificador de acción y sus parámetros. Esa parte es fácil de escribir a mano.

El archivo tiene que estar firmado antes de que alguien pueda abrirlo, y macOS incluye una CLI para eso:

shortcuts sign --mode anyone --input mine.plist --output mine.shortcut

Pero rechaza plists escritas a mano. XML, binario, un archivo de una sola acción, un set completo de acciones válidas… nada funciona. El error no es descriptivo: “no se pudo abrir el shortcut”. Tras revisar con un reverse engineer, el problema está en que la firma incluye un hash de todo el archivo, y macOS verifica que el contenido coincida con lo que Apple espera. Pero no hay documentación pública del formato exacto.

La moraleja: no puedes generar un .shortcut desde código. O lo construyes en el iPhone, o no lo tienes.

Muro 2: iCloud Drive no es un reemplazo de Git

Mi siguiente intento fue construir el shortcut en el teléfono y luego sincronizarlo a mi Mac vía iCloud, para versionarlo con Git.

El shortcut aparecía en ~/Library/Mobile Documents/com~apple~Shortcuts/. Pero el archivo que ves en Finder no es el shortcut real — es un contenedor con metadatos de iCloud. Si lo copias a otra máquina, se rompe.

Además, cada vez que abres el shortcut en el editor, se regenera el archivo con un nuevo identificador UUID interno. Hacer git diff entre dos versiones mostraba cambios en 90% del archivo aunque solo hubieras movido un paso. Inútil para revisión de código.

Muro 3: no hay API para desplegar shortcuts

En un equipo, necesitas que todos tengan la misma versión del shortcut. En un mundo ideal, tendrías un pipeline: commit → build → deploy a todos los iPhones del equipo.

Apple no ofrece nada parecido. La MDM (Mobile Device Management) empresarial no soporta distribución de shortcuts. No hay API de App Store Connect para shortcuts. No hay TestFlight para shortcuts.

La única opción es compartir manualmente un enlace de iCloud, que abre el shortcut en el editor y pide al usuario que lo instale. Cada vez que actualizas, repites el proceso. En un equipo de 5 personas, eso son 5 instalaciones manuales. En un equipo de 50, es inviable.

Muro 4: no hay testing automatizado

¿Cómo pruebas un shortcut que interactúa con APIs externas? No hay shortcuts test, no hay un sandbox, no hay mocks.

Probé envolver la lógica en una función de Node.js que hiciera lo mismo, pero entonces ya no era un shortcut — era un script. Y si es un script, ¿para qué usar Shortcuts?

Lo que aprendí

Apple Shortcuts es excelente para automatización personal de un solo usuario. Para eso fue diseñado y en eso es imbatible: “Hey Siri, envía un mensaje” o “Apaga las luces a las 10 PM”.

Pero como plataforma para ingeniería de software — con CI/CD, control de versiones, despliegue a múltiples dispositivos y testing automatizado — simplemente no existe. Y Apple no ha dado señales de que vaya a cambiar esto.

Si tu caso de uso es personal, adelante. Shortcuts es una herramienta fantástica. Pero si necesitas automatización distribuida a nivel de equipo, busca otro camino: un bot de Slack, una función serverless, o incluso un script de Python con un cron job.

“El shortcut perfecto es el que no necesitas construir desde código.”

¿Has chocado contra este muro intentando automatizar Shortcuts para algo serio? ¿Cuál fue tu experiencia?