Apple Foundation Models: qué pueden hacer los desarrolladores Mac independientes con IA en el dispositivo

Por unos tres años, cada desarrollador independiente que quería enviar “funciones de IA” tuvo que tomar la misma decisión incómoda. O pagar una factura de OpenAI o Anthropic que escalaba linealmente con los usuarios, o saltarse las funciones de IA por completo. La matemática para una app de pago único era brutal. Unos centavos por usuario al mes destruyen el margen de una app de $9.99 de por vida en meses.

El framework Foundation Models de Apple, anunciado en WWDC 2025 y enviado en macOS 26 (Tahoe), cambia la matemática. El framework le da a los desarrolladores acceso programático al mismo modelo de lenguaje en el dispositivo que impulsa las funciones de Apple Intelligence en el Mac del usuario. El modelo corre localmente. Tu app no paga por inferencia. El usuario no necesita una clave de API. El texto nunca sale del dispositivo.

Esta entrada es un recorrido práctico por lo que los desarrolladores independientes pueden hacer realmente con el framework, en qué no es bueno, y qué significa el cambio arquitectónico para una app Mac enfocada.

Qué obtienes

El framework expone una LanguageModelSession que puedes prompttear con texto. El modelo responde con texto, y opcionalmente con un objeto estructurado que especificas con el macro @Generable. El modo de salida estructurada es el más útil para la mayoría de las apps porque te permite decir “devuélveme JSON conforme a este esquema” en vez de intentar parsear texto libre.

Un flujo típico se ve así:

1. Crea una sesión con instrucciones de sistema que describan la tarea del modelo.
2. Envía un mensaje de usuario.
3. Lee la respuesta estructurada.
4. Usa la respuesta para impulsar tu app.

Todo esto corre en milisegundos para prompts cortos y unos pocos segundos para los largos. No hay llamada de red. No hay clave de API. No hay límite de tasa más allá de lo que el dispositivo en sí pueda sostener.

En qué es realmente bueno el modelo

El modelo en el dispositivo es pequeño comparado con un modelo de la nube de última generación. No es GPT-4. Tratarlo como tal llevará a la decepción. Donde brilla es en una clase específica de tareas:

• Clasificación. “¿Es esta cadena una frase de fecha o no?” “¿A cuál de estas cinco categorías pertenece esta tarea?” Estas son tareas que el modelo en el dispositivo maneja con fiabilidad y rapidez.
• Extracción estructurada. Sacar campos específicos de una entrada de texto libre. “¿Qué hora del día referencia esta frase?” “¿Cuál es el verbo en esta frase?” El modo de salida estructurada del framework está construido para esto.
• Reescritura corta de texto. Convertir una nota informal en un título limpio, resumir un párrafo en una sola frase, arreglar la gramática en un borrador. El modelo es bueno en transformaciones de texto pequeñas y contenidas.
• Cambios de tono. Hacer un borrador más cálido, más conciso, o más profesional. La misma restricción: entradas cortas, salidas contenidas.

Esto es la mayoría de lo que una app de productividad necesita realmente. Nota lo que no está en la lista: generación de formato largo, razonamiento complejo, preguntas de conocimiento del mundo, generación de código. El modelo en el dispositivo puede hacer esas cosas, pero no tan bien como un modelo de la nube. Si esas son centrales para tu producto, todavía necesitas la nube.

En qué no es bueno el modelo

Tres clases de tarea donde deberías buscar otra cosa:

1. Contexto largo. El modelo en el dispositivo tiene una ventana de contexto más pequeña que un modelo de la nube. Darle un documento de 50 páginas y pedir análisis no irá bien. Dale el extracto relevante en su lugar.
2. Escritura creativa abierta. Puede hacer escritura creativa corta, pero notarás la diferencia comparado con un modelo de la nube de frontera. Si tu app es un asistente de escritura para novelistas, este probablemente no es tu modelo.
3. Tareas donde el usuario espera calidad de última generación. Si tus usuarios van a comparar tu salida con ChatGPT y juzgar en consecuencia, vas a perder. El modelo es excelente para utilidad invisible, menos para tareas donde la IA es el producto visible.

El encuadre correcto es: usa el modelo en el dispositivo para hacer la app más inteligente en segundo plano, no para ser el producto visible.

Qué significa esto para los precios independientes

La consecuencia más interesante del modelo en el dispositivo es la implicación de precios. Por la mayoría de los últimos tres años, el consejo estándar para desarrolladores independientes enviando funciones de IA era “tienes que cobrar una suscripción, porque los costes de inferencia son reales y recurrentes.” Ese consejo era correcto.

Ya no es correcto para apps donde la inteligencia en el dispositivo es suficiente. La razón entera por la que una app de pago único no podía enviar IA era el coste recurrente. Si el coste recurrente es cero, el modelo se rompe. Puedes enviar funciones de IA en una app de pago único y no quebrar.

Esto es importante para la pequeña ola de apps independientes para Mac intentando revivir el modelo de pago único. Escribimos sobre la tendencia más amplia pero la pieza de IA es una de las razones técnicas reales por las que funciona en 2026.

Cómo empezar

El framework es parte del SDK estándar de Apple en macOS 26. No hay descarga separada. No hay clave de API. No hay cuenta que crear. Añade import FoundationModels a un archivo Swift, crea una LanguageModelSession, envía un prompt, lee la respuesta.

El modelo está disponible en Macs con Apple Silicon que cumplen los requisitos de sistema para Apple Intelligence. Macs Intel más viejos no obtienen el framework, así que tu app necesita una estrategia de respaldo si quieres soportarlos. Para la mayoría de las apps independientes Mac que se envían hoy, una verificación de disponibilidad y un camino de degradación elegante son suficientes. El usuario sin el modelo obtiene la versión basada en regex de la función; el usuario con el modelo obtiene la versión más inteligente.

Cómo se ve esto en TodoBar

TodoBar usa el framework como respaldo para el procesamiento de fechas en lenguaje natural. El camino rápido son expresiones regulares, que atrapan alrededor del 90% de las frases de fecha en menos de un milisegundo. Cuando el camino de regex falla, el modelo en el dispositivo lo intenta, con una latencia típica de unos 50 milisegundos, y devuelve una clasificación estructurada de lo que el usuario quiso decir. Describimos el pipeline completo en la entrada de procesamiento de fechas.

El modelo es invisible para el usuario. No saben que está ahí. Solo notan que “en un par de horas” funciona igual que “en 2 horas.” Eso es lo que se siente como buena IA en el dispositivo.

También es por qué una app de pago único de $9.99 puede enviar una función que habría requerido una suscripción hace un año. La matemática por fin funciona.