LLMs on-device en apps Flutter: qué cambió en 2026 con Apple Foundation Models (y cómo integrarlo)
La pregunta directa: ¿puedes ejecutar un modelo de lenguaje dentro de tu app Flutter, sin nube, gratis y con los datos del usuario sin salir del dispositivo? En 2026 la respuesta es sí, y el cambio decisivo lo trajo la WWDC 2026: el Foundation Models framework de Apple dejó de ser un jardín cerrado. Este artículo explica qué es lo nuevo, cómo se integra desde Flutter y —fieles a la casa— cuándo el on-device es la decisión equivocada.
Qué cambió en 2026
Hasta la WWDC 2026, el Foundation Models framework (disponible desde iOS 26) tenía una regla: o usabas el modelo on-device de Apple, o nada. Esa regla desapareció. Apple abrió un protocolo público de proveedores que permite enchufar cualquier LLM al mismo framework, manteniendo la misma lógica de sesión. En la práctica, un desarrollador puede alternar entre:
- Modelo on-device de Apple (~3B parámetros): gratis, privado, offline.
- Modelo en la nube de Apple (Private Cloud Compute): más contexto y razonamiento.
- Modelos empaquetados propios, distribuidos vía Swift Package Manager.
- Modelos en formato MLX desde Hugging Face.
- APIs de terceros (Gemini y Anthropic ya integrados).
Para el desarrollador, la ventaja no es solo la variedad: es que la gestión de sesión, el bucle de tool calling y el manejo de errores son los mismos independientemente de qué modelo esté detrás. Cambias la fuente sin reescribir la lógica.
En Android el equivalente es Gemini Nano vía AICore, orquestado con LiteRT-LM y gestión de sesión con caché de prompts integrada. Dos ecosistemas, la misma idea: inferencia local en el silicio del teléfono.
Qué sabe hacer un modelo on-device (y qué no)
Un modelo de ~3B parámetros en el Neural Engine no es GPT en tu bolsillo. Rinde en tareas enfocadas: resumen, extracción, clasificación, generación de texto corto, respuestas rápidas tipo Smart Reply. Para contexto largo, razonamiento abierto o conversaciones de muchos turnos, sigues necesitando la nube.
El patrón de diseño que Apple promueve —y que tiene sentido adoptar— es en cascada: el dispositivo intenta resolver primero; si la petición encaja (resumir, traducir, clasificar), nunca sale del teléfono; si es demasiado compleja, escala a Private Cloud Compute o a una API. Diseñar para esa frontera es la clave de una buena UX de IA en móvil.
Cómo se integra desde Flutter
Flutter no habla Swift ni Kotlin directamente, así que la integración pasa por platform channels (method channels) que puentean la capa Dart con el código nativo que invoca Foundation Models en iOS o AICore en Android.
Ya existe ecosistema para no partir de cero: hay un paquete comunitario (foundation_models_framework, publicado en pub.dev) que envuelve el framework de Apple y expone desde Dart sesiones persistentes, streaming de tokens en tiempo real, opciones de generación (temperatura, límite de tokens), historial de transcript con roles y niveles de guardarraíl con validación de prompt. Requiere iOS 26.0+ / macOS 15.0+.
El esqueleto conceptual de una integración propia con method channel:
// Capa Dart
const _channel = MethodChannel('app/on_device_llm');
Future<String> summarize(String text) async {
final result = await _channel.invokeMethod<String>('summarize', {
'prompt': text,
'maxTokens': 256,
});
return result ?? '';
}
// Capa nativa iOS (esquema): el handler traduce la llamada Flutter
// a una LanguageModelSession del Foundation Models framework,
// hace streaming de la respuesta y la devuelve por el channel.
Del lado nativo, el framework trabaja con entradas tipadas (Transcript) y devuelve deltas de texto por streaming junto con metadatos de uso de tokens. Si necesitas soportar un proveedor propio, implementas los protocolos LanguageModel (declara capacidades: tool calling, guided generation, razonamiento) y LanguageModelExecutor (hace la generación real y mapea al formato del modelo).
Si prefieres un modelo abierto y control total del binario, la vía alternativa es empaquetar un modelo cuantizado (por ejemplo un Gemma pequeño) y ejecutarlo con method channels en ambas plataformas, a costa de peso de app y de gestionar tú el ciclo de vida.
On-device vs. nube: cómo elegir
| Criterio | On-device | Nube (API/PCC) |
|---|---|---|
| Coste por petición | Cero | Por token |
| Privacidad | Datos no salen del móvil | Salen al proveedor |
| Offline | Sí | No |
| Latencia | Baja y constante | Depende de red |
| Capacidad de razonamiento | Limitada (~3B) | Alta |
| Contexto largo | No | Sí |
| Peso de la app / batería | Impacto real | Ninguno |
Cuándo NO usar on-device
El on-device se vende como la opción "gratis y privada", pero no siempre es la correcta:
- Si tu caso necesita razonamiento o contexto largo. Forzar un modelo de 3B a una tarea que le queda grande produce respuestas pobres; ahí la nube no es opcional.
- Si tu base de usuarios tiene hardware antiguo. Foundation Models exige iOS 26+ y chips recientes; Gemini Nano depende de AICore y dispositivos compatibles. Sin fallback a nube, dejas fuera a parte de tus usuarios.
- Si el peso de la app o el consumo de batería son críticos para tu segmento. Empaquetar modelos propios engorda el binario; la inferencia continua calienta y drena.
- Si buscas una respuesta idéntica en todas las plataformas. El modelo de Apple y Gemini Nano no dan la misma salida; si tu producto exige consistencia exacta cross-platform, un único modelo en nube simplifica.
La recomendación honesta: usa on-device para lo que hace bien (privacidad, coste cero, offline, tareas cortas) y arquitectura una estrategia híbrida con fallback en lugar de apostar todo a un solo camino.
Cómo lo enfocamos en Dribba
Llevamos desde 2011 construyendo apps con Flutter y, más recientemente, integrando IA on-device de forma pragmática. Nuestro criterio: primero definimos la frontera dispositivo/nube según el caso de uso y el parque de dispositivos real del cliente; después medimos latencia, batería y calidad de salida con datos, no con demos; y siempre dejamos un fallback a nube para no romper la experiencia en hardware que no llega.
Si quieres profundizar, este artículo complementa nuestra guía sobre Edge AI en dispositivos móviles, el análisis del impacto de Gemini en Flutter y el trabajo de interoperabilidad nativa con FFIgen, JNIgen y Swift Package Manager, la base técnica sobre la que se apoya cualquier puente a estos frameworks.
Conclusión
2026 convirtió el LLM on-device de experimento en opción de producción: Apple abrió su Foundation Models framework a cualquier proveedor y Android consolidó Gemini Nano vía AICore. Desde Flutter, el puente son los platform channels, con paquetes que ya te ahorran el andamiaje. Pero la decisión de fondo sigue siendo de arquitectura: qué resuelve el dispositivo, qué escala a la nube, y qué fallback proteges. Ahí es donde un producto de IA en móvil se gana —o se pierde.
¿Estás valorando IA on-device para tu app y quieres decidir la frontera dispositivo/nube con criterio? En Dribba diseñamos e implementamos esa arquitectura con equipo 100% senior in-house. Hablemos.
