1 puntos por GN⁺ 3 시간 전 | 1 comentarios | Compartir por WhatsApp
  • Un paquete de Swift que conecta Claude como modelo del lado del servidor al framework Foundation Models de Apple, permitiendo a los desarrolladores llamar a Claude con la misma ruta de código que el modelo on-device de Apple
  • Gracias al protocolo LanguageModel introducido por Apple en la WWDC 2026, ahora es posible una arquitectura híbrida con una sola API estándar: prototipar con el modelo on-device y derivar solo las tareas complejas a un modelo en la nube
  • La clave es la capacidad de intercambiar proveedores: se puede pasar entre Apple, Claude y Gemini cambiando solo la dependencia del Swift Package, sin tocar la lógica de sesión
  • Este paquete, publicado por Anthropic bajo Apache 2.0, es el primer ejemplo funcional de esa idea de “conectar cualquier backend”
  • Las solicitudes van directamente de la app a la API de Claude y Apple no está en la ruta, por lo que no puede ver los prompts ni las respuestas; además, el costo se factura directamente a la cuenta de Anthropic

Por qué importa

  • Hasta ahora, integrar un modelo de lenguaje en una app de iOS implicaba registrarse en una API de nube por separado, administrar claves, pagar por token y enviar todos los prompts fuera del dispositivo; en la WWDC 2026, Apple resolvió esa incomodidad de larga data
  • El framework Foundation Models se amplió para invocar, mediante una sola API nativa de Swift, tanto los modelos on-device de Apple Intelligence como Private Cloud Compute y nubes de terceros como Claude y Gemini
  • Anthropic publicó un paquete de Swift que implementa este nuevo protocolo. Sirve para tomar el relevo del modelo on-device de Apple y llamar a Claude para manejar flujos de trabajo más complejos

Qué cambia para los desarrolladores

  • Cambio de proveedor sin modificar el código

    • Después de prototipar una app con el modelo on-device de Apple, es posible enrutar consultas complejas a Google Gemini o Anthropic Claude, o alternar entre ellos, actualizando solo la dependencia en Swift Package Manager, sin cambiar la lógica de sesión ni el resto del código de la app
    • El modelo on-device se usa para tareas rápidas y locales como resumen y extracción, y solo se hace handoff a Claude cuando se necesita razonamiento de varios pasos, generación de código, búsqueda web o ejecución de código
    • En ambos casos se usa la misma API LanguageModelSession, así que basta con cambiar el argumento model:
  • Handoff basado en tipos

    • Tras agregarlo al proyecto e iniciar sesión con una clave de API de Anthropic, se puede pasar la salida tipada del modelo on-device de Apple a una solicitud para Claude, y el paquete vuelve a manejar streaming, llamadas a herramientas y respuestas estructuradas hacia las vistas de SwiftUI
    • Su uso es tan simple que, mediante generación guiada, puede devolver valores tipados de Swift con solo tres líneas de código

Estructura de privacidad y costos

  • Las solicitudes se envían directamente desde la app a la API de Claude, por lo que Apple no está en la ruta de la solicitud y no puede ver los prompts ni las respuestas
  • El uso se factura directamente a la cuenta de Anthropic con los precios estándar de la API
  • La app decide directamente en cada sesión si usar Claude o el modelo on-device de Apple

El panorama más amplio

  • Apple planea convertir en open source este verano el framework Foundation Models, una API nativa de Swift para modelos on-device lanzada en 2025, y con el nuevo protocolo LanguageModel casi cualquier modelo, ya sea propio de Apple o de un proveedor remoto, puede hacer funcionar LanguageModelSession detrás de una sola API de Swift
  • Como ejemplo de ese “conectar cualquier backend”, ClaudeForFoundationModels de Anthropic materializa el patrón adaptador
  • Apple también permite, con su sistema Dynamic Profiles, que las apps cambien modelos, herramientas e instrucciones a mitad de una sesión, y lo posiciona como base para flujos de trabajo multiagente
  • Aun así, esta integración está en fase beta y requiere iOS, iPadOS, macOS, visionOS, watchOS 27 y Xcode 27, por lo que la API todavía podría cambiar antes del lanzamiento oficial

1 comentarios

 
GN⁺ 3 시간 전
Comentarios de Hacker News
  • Apple está controlando la experiencia de usuario mientras convierte a los LLM en un commodity
    Como buena empresa de hardware, la estrategia parece ser seguir vendiendo las mejores máquinas para usar IA, y parece una buena decisión

    • Puede que Benedict Evans al final haya tenido razón. Los modelos frontier se parecen cada vez más a las telecomunicaciones de los 90
      Invierten miles de millones de dólares en infraestructura, pero el valor se lo llevan otras empresas en capas superiores
    • Un poco aparte de eso de controlar la experiencia de usuario, este es el resultado de la IA que más me gusta. Durante décadas las empresas cercaron sus servicios y forzaron interfaces horribles, pero en los últimos 12 meses de repente todo tiene MCP y se puede usar con una interfaz de chat en línea de comandos
      Las empresas que no se adapten van a terminar siendo golpeadas por scrapers web DIY basados en IA hechos por la gente hasta que no les quede más que ceder
    • No sé si la mejor máquina para usar IA es la expresión correcta aquí. ¿Estos modelos no siguen corriendo del lado del servidor?
    • Desde hace años estaba claro que la IA terminaría integrada a nivel del sistema operativo. Apple ya lo reconocía cuando presentó por primera vez Apple Intelligence
      Tal vez sí encaje eso de convertir a los LLM en un commodity, pero esto ya es una función orientada al usuario que vienen puliendo desde hace años
    • Ahora solo falta convertir el hardware en commodity
  • Que sea un paquete de Swift para permitir usar Claude como modelo de lenguaje del lado del servidor en Apple's Foundation Models framework no era lo que esperaba; yo esperaba lo contrario. Quería que las funciones existentes de Claude Code somehow corrieran localmente en el Neural Engine de mi laptop
    Con un M2 y 8GB de RAM es una fantasía, pero por un momento tuve esperanza

    • Ve esta sesión de WWDC. Obviamente no puede competir con los modelos frontier y 8GB también me parece demasiado poco, pero Apple sí hizo una demo de MLX + OpenCode
      https://developer.apple.com/videos/play/wwdc2026/232/
      https://www.youtube.com/watch?v=wykPErJ8M-8
    • Si usas OpenCode o Pi con streaming desde SSD, técnicamente podrías tener todas las funciones. Eso sí, sería insoportablemente lento
    • La mayoría de los modelos frontier para programación parecían necesitar entre 300GB y 1TB para usar bien todas sus capacidades
    • Claude Code puede configurarse mediante variables de entorno para consultar literalmente cualquier endpoint que quieras, siempre que tenga una API compatible
    • Si la nube en realidad fuera el iCloud privado del usuario, me parecería bien. Si el usuario paga el costo y se ejecuta cerca de los servidores de Apple donde ya se guardan iPhotos, podría ser una solución muy elegante
      Pero en la práctica terminas recibiendo Claude sin saber siquiera dónde está alojado. Podría ser un centro de datos de X-AI, podría ser en algún lugar de Amazon, nadie sabe
  • Esto no es exclusivo de Claude. Los desarrolladores también pueden crear apps que llamen a los modelos Gemini basados en servidor de Google
    En la WWDC, Apple anunció que abriría Foundation Models framework a proveedores externos de modelos en la nube. A partir de iOS 27, macOS 27, iPadOS 27, visionOS 27 y watchOS 27, los proveedores de modelos podrán implementar el nuevo protocolo público LanguageModel para ofrecer una interfaz común para la inferencia de modelos. Google habilitó el uso de modelos Gemini dentro de Foundation Models framework a través del Firebase Apple SDK
    Esto permite una experiencia de desarrollo totalmente nativa. Los modelos Gemini alojados en la nube pueden conectarse directamente a Foundation Models framework mediante la misma API, y como los modelos de Apple en el dispositivo y los modelos Gemini alojados en la nube quedan detrás de una superficie API común, es fácil alternar entre inferencia local e inferencia en la nube según el caso de uso
    https://blog.google/innovation-and-ai/technology/developers-...

    • Lo importante es que Apple básicamente le cambió el nombre a la API compatible con OpenAI y la llamó language model protocol, y antes de que todos quedemos malditos por esa expresión horriblemente larga, deberíamos unirnos rápido a este lado
  • Me alegra que Apple haya introducido este tipo de abstracción, pero mi principal preocupación va por el lado de los modelos locales
    Por ejemplo, aunque quisieras usar Gemma4, desde la perspectiva del usuario, si 10 apps descargan cada una el mismo modelo, el teléfono se infla innecesariamente
    Todavía no entiendo si Apple ofreció una forma para que varias apps puedan usar el mismo modelo dentro del dispositivo. Debería poder hacerse sin trucos complicados de namespaces o permisos
    No he visto nada que sugiera eso

    • Creo que eso es justamente lo que Apple está tratando de evitar. Si se necesita inteligencia en el dispositivo, su propuesta es algo como “el mejor modelo es el que ya está en el dispositivo”, y si hace falta algo más específico, la mejor opción serían adaptadores, es decir, fine-tuning/LoRA
      Estaba equivocado cuando los modelos en dispositivo se quedaban muy atrás, pero a largo plazo todavía podría tener razón
      Puede que varias apps que uso necesiten Gemma 4 E4B, pero uso decenas de apps y los desarrolladores pueden elegir entre cientos de modelos. Un caché compartido podría ahorrar un poco de espacio cuando coincidan, pero el problema central sigue ahí. Si cada app elige su modelo, el disco y el swapping de memoria explotan
      Es muy posible que sea mejor que el fabricante del dispositivo incluya un valor predeterminado. No digo que haya que impedir el uso de otros modelos, pero un único valor compartido por defecto podría ser lo mejor para el 99% de las apps, tanto para la experiencia del desarrollador como para la del usuario
      Que ya esté cargado en memoria es la mayor mejora de rendimiento, y es mucho más probable que el modelo predeterminado se mantenga caliente
      El “mejor modelo” normalmente es “el mejor modelo para este dispositivo” considerando RAM y capacidad de cómputo. Los desarrolladores no pueden probar todos los dispositivos, pero Apple sí puede y lo hará
      Cada modelo debe optimizarse para el hardware. Importa dónde corre qué: ANE, Metal o CPU, y el modelo predeterminado estará optimizado
      Si hace falta un modelo personalizado, probablemente LoRA sea lo mejor. Ocupa unos 30 MB y permite aprovechar todas las ventajas anteriores
      Se puede argumentar que el predeterminado debería poder reemplazarse, pero eso está más cerca de un ideal tipo Linux que de Apple, así que dudo que lo veamos en la práctica. Además, tiene desventajas reales. Quieras o no, los prompts se optimizan para el modelo objetivo del desarrollo, así que si cambias el modelo del sistema por defecto, la calidad de todas las apps puede empeorar
    • Esta es una buena oportunidad para que Apple ofrezca un protocolo universal de ID única de modelos y almacenamiento compartido, para que los desarrolladores registren modelos
    • Hay que ver “Bring an LLM provider to the Foundation Models framework”
      https://developer.apple.com/videos/play/wwdc2026/339
    • Las apps pueden usar el modelo en dispositivo que provee el sistema con el mismo framework y la misma API. Pero no hay ningún mecanismo para eliminar duplicados entre modelos personalizados de distintas apps
    • Eso es precisamente foundation models. AICore de Android también usa Gemma internamente, y en vez de que las apps empaqueten su propio modelo, terminan consultando al LLM y recibiendo una respuesta
  • Me pregunto si Apple está empujando a los desarrolladores a usar LLM a través de su propia capa de abstracción de API. Tal vez sea para que, cuando lancen su propio LLM más adelante, los desarrolladores puedan cambiarse sin fricción
    Creo haber escuchado que Apple está gastando mucho dinero en entrenamiento y que de alguna manera podría estar relacionado con Siri o con la Apple AI actual. No sé si es solo una función de conveniencia para desarrolladores o si hay otra intención detrás

    • Apple tiene mecanismos bastante ingeniosos para proteger los datos del usuario. Hace poco tuve que trabajar en temas de seguimiento de apps y, antes de reportar eventos de tracking a plataformas de terceros, la forma en que ocultan los detalles del usuario dentro de cohortes anonimizadas con SKAN y privacidad diferencial estaba mejor diseñada de lo que esperaba
      Si valoras la privacidad, tiene sentido que Apple se meta en el medio
    • Esto es soporte para un framework nuevo incluido en reality/mac/iPad/watch/tv/iOS 27. Dijeron que lo abrirán como open source a finales de este año, así que también parece que podrá aprovecharse al desplegar Swift en backend
      El punto clave de este framework es que, con la misma API, puedes apuntar tanto a modelos integrados en el dispositivo, como al modelo online hospedado por Apple, Private Cloud Computer, o a un shim propio que invoque cualquier modelo online hospedado arbitrariamente
      Entonces, en lugar de construir tu propia capa de abstracción para algo como “esto lo quiero con un modelo local y aquello con Claude”, o integrar directamente las API de Anthropic/OpenAI, puedes usar la API del sistema para enrutar dinámicamente las llamadas entre distintos tipos de modelos/proveedores
      Hay varias comodidades y particularidades, como abstraer en un solo lugar cosas como tool calling, o seguir usando el mismo transcript durante una sesión aunque cambies dinámicamente de proveedor o de modelo
    • Visto con cinismo, o con realismo, esta capa de abstracción parece la manera de Apple de hacer que los usuarios atribuyan la función a Apple Intelligence, aunque el LLM real lo provea otra empresa
    • Es una interpretación oscura, pero no del todo injusta. A Apple le resultará más fácil cobrar por modelos provistos por otras empresas y, si quisiera, también podría recopilar datos sobre cómo los usuarios usan modelos de terceros para construir datasets de entrenamiento para sus propios modelos
      Como esta API solo se usa en dispositivos Apple, también fragmenta el mercado e intensifica el lock-in del usuario, porque para que algo funcione bien en iOS el desarrollador termina sin poder usar el mismo sistema en otros lados
    • Ya existe un modelo en dispositivo que los desarrolladores pueden usar a través de este framework. Claude es solo un modelo más que se suma ahí
  • Parece que Apple se está preparando para que sus modelos en dispositivo mejoren, y tiene sentido si pensamos que ya se obtuvo acceso a Gemini
    Si los desarrolladores escriben todo el código para llamar LLM externos usando esto, cuando los modelos de Apple sean más capaces y cubran más casos de uso, podrán cambiarlo fácilmente en cada punto de llamada. Entonces mejorará la experiencia de usuario de la app y también bajarán los costos de facturación del desarrollador, de los que Apple no se lleva comisión

    • Dicho de otro modo, como no da dinero, es poco probable que pase. A Apple le convendría más crear nuevos planes de IA y IA-lite a los que la gente pueda suscribirse
      Apple es una empresa, y todos sabemos qué es lo que les importa a las empresas, así que no parece muy probable una utopía donde modelos locales corran en el teléfono
    • No entiendo cómo usar Gemini hace que los modelos en dispositivo mejoren
    • Experiencia de usuario es otra forma de decir construcción de ecosistema, y eso es lo que Apple hace mejor que sus competidores. Tampoco le hace daño tener hardware que encaje con eso
      No es casualidad que Microsoft y Nvidia estén asociados
  • Me pregunto cómo se usaría esto realmente en software que se distribuye a usuarios. Pedirle al usuario que cree e ingrese directamente una API key es una barrera demasiado alta para una buena experiencia de usuario

    • Una barrera todavía mayor es hacer que un usuario común, o sea alguien que no es desarrollador, acepte la tarificación basada en tokens
      La idea de “pagar dinero sin saber cuánto costará una sola pregunta, quizás no obtener la respuesta que querías, y tener que pagar más si lo usas más” no resulta atractiva para la mayoría, salvo para los apostadores. Explicar que un “gracias” al final de una conversación larga puede salir caro por el contexto es todavía más difícil de aceptar para el usuario promedio
      Tampoco ayuda que el costo por tokens suba y baje como yo-yo. El usuario común necesita un costo fijo y no quiere gastar energía siguiendo constantemente el flujo de la IA. Problemas como “el mes pasado mi suscripción duró mucho más” tampoco van en una buena dirección
      En la mayoría de los casos, creo que Apple tiene razón al pensar que el futuro son los LLM locales
    • Totalmente. Manejo allihat.com, y creo que sigue siendo la única extensión de Safari que se comunica con Claude, y además hay bastante demanda. Pero el usuario tiene que ingresar por su cuenta la maldita Claude API key
      Tampoco termino de entender los términos de Anthropic. Se puede ingresar algo como setup-token Set up a long-lived authentication token (requires Claude subscription), pero parece una trampa. No sé quién usaría eso, y me da la impresión de que si lo usas en cualquier lado ya estás violando los términos de inmediato
      Ahora mismo en allihat.com, si no quieres usar una clave de Claude, puedes usar un modelo local de Apple, y la conversión a usuarios pagos subió como 3 veces. Pero obviamente no es un reemplazo de Claude. Ojalá Apple creara algún mecanismo para hacer de proxy de Claude por nosotros. Así yo tampoco tendría que hacer proxy a través de mi propio servidor solo para gestionar el uso de la API de Claude
    • En producción dice que enrutes las solicitudes con .proxied a través de tu propio backend
      Apple está ofreciendo modelos de IA gratuitos a través de sus propios servidores para desarrolladores con menos de 2 millones de descargas https://techcrunch.com/2026/06/08/apple-bets-cheaper-ai-will...
    • Como siempre: haces proxy de las solicitudes a través de tu propio backend
    • No es que el usuario te dé una API key. La documentación explica cómo configurar un proxy de backend
  • Entiendo que la frase “Las solicitudes van directamente desde la app a la API de Claude, Apple no está en la ruta de la solicitud y no ve ni los prompts ni las respuestas” está escrita desde la perspectiva del desarrollador
    Pero desde el punto de vista del consumidor simplemente da risa

    • ¿Por qué?
  • Microsoft fue quien rompió el juego primero al poner en los términos de Copilot que “Copilot se proporciona solo con fines de entretenimiento”, y además al poner en Copilot para Excel la advertencia de “evita usar COPILOT para trabajo que requiera exactitud o reproducibilidad, o que tenga implicancias legales, regulatorias o de cumplimiento”
    Después Apple está rechazando discretamente sumarse, sin invertir decenas o cientos de miles de millones de dólares en crear un LLM competidor. Claro, revenderán Claude o aprovecharán Gemini para la gente ingenua, pero Apple entiende la situación
    https://www.microsoft.com/en-us/microsoft-copilot/for-indivi...
    https://support.microsoft.com/en-US/Excel/copilot-function

  • Los agentes de programación ya son una capa impuesta de por sí, así que esto parece agregar otra capa más. Muchas veces los agentes de programación se sienten como el gerente de proveedores de una agencia de contratación de los 90
    Le prometen al cliente absolutamente todo bajo el sol, y luego presionan al pobre contratista para que entregue. Los agentes de programación consumen 10 veces más tokens, igual que la diferencia entre lo que la agencia le cobraba al cliente y lo que le pagaba al contratista. Como prueba sencilla, una tarea en la que el modelo supera la longitud de contexto cuando pasa por el agente de programación funciona bien si le haces el prompt directamente
    Las capas son un lujo, y eliminan control y transparencia

    • Yo no usaría esto para hacer agentes de programación