La pregunta llega casi siempre con las mismas palabras: «tenemos la app en Flutter, ¿cuánto cuesta sacarla también en la pantalla del coche?». La respuesta corta decepciona un poco. No sacas tu app. Ni CarPlay ni Android Auto ejecutan tu interfaz Flutter en el salpicadero. Lo que construyes es una superficie nueva, dibujada con las plantillas que imponen Apple y Google, y solo si tu caso encaja en una de las categorías que ellos aprueban. Lo que sí reutilizas de Flutter es todo lo que vive por debajo de la pantalla: tu lógica de dominio, tu capa de datos, tu backend.
Merece la pena entender por qué antes de presupuestar nada.
Por qué no se trata de portar la app
Apple y Google parten de la misma premisa: quien va al volante no puede perder la vista en una interfaz libre. Por eso ninguna de las dos plataformas te deja renderizar UI arbitraria en la pantalla del coche. Ambas exponen un conjunto cerrado de plantillas (listas, rejillas, mapas, alertas, reproductor) cuyo aspecto controlan ellas. Tú les pasas datos; ellas los pintan. La única excepción es el lienzo de mapa que reciben las apps de navegación, y aun ahí con reglas estrictas.
El modelo mental que funciona es otro: un cliente ligero, reducido a tres o cuatro tareas, montado sobre la misma lógica que ya tienes. Si interiorizas eso, el resto de decisiones se ordena solo.
CarPlay: primero el permiso, luego las plantillas
En CarPlay el orden importa. Antes de escribir una línea necesitas un entitlement que Apple concede por categoría, no de forma automática, y que una app generalista no obtiene. Lo solicitas desde la página de CarPlay de Apple, aceptas el addendum correspondiente y hay una espera por medio.
Las categorías cubren un terreno concreto: audio, comunicación y mensajería, navegación, carga de vehículo eléctrico, aparcamiento, repostaje, pedido rápido de comida y tareas de conducción. Desde iOS 26.4, en febrero de 2026, se sumaron las apps conversacionales de voz. La de recarga de VE tiene su propia clave (com.apple.developer.carplay-charging), y las combinaciones entre categorías están tasadas: Apple documenta, por ejemplo, poder unir carga y repostaje.
Cada categoría habilita un subconjunto de plantillas: lista, rejilla, información, barra de pestañas, reproductor, alerta, hoja de acciones. El lienzo libre donde dibujas tu propio mapa queda reservado a navegación. Para un operador de recarga, esto significa un camino claro hacia el coche. Para una app de ecommerce o productividad genérica, significa que no hay puerta de entrada, por mucho presupuesto que haya detrás.
Android Auto: categorías aprobadas y niveles de API
Google funciona igual de arriba abajo, con su Android for Cars App Library. También va por plantillas y también por categoría aprobada. Las habilitadas hoy son navegación, puntos de interés (que incluye aparcamiento, carga y gasolineras), IoT y, desde 2025, meteorología.
Hay dos matices que conviene no pasar por alto. El primero: las plantillas se liberan según el nivel de API de la librería, así que algunas funciones piden un nivel mínimo y tu app tiene que declararlo. El segundo: Android Auto (proyección desde el móvil) no es lo mismo que Android Automotive OS (el sistema embebido en el coche). Comparten la librería de plantillas, pero la distribución, las pruebas y el ciclo de publicación cambian. Decide pronto a cuál apuntas.
Qué parte de tu Flutter sí viaja al coche
Y aquí Flutter rinde. Todo lo que no es pantalla se reutiliza: la lógica de dominio, los repositorios, los clientes de API, la autenticación, la caché offline. Es Dart que ya tienes probado y que no reescribes.
La superficie del coche, en cambio, es nativa. La construyes con las plantillas de CarPlay (Swift) y de Android Auto (Kotlin), y la gobiernas desde Dart a través de platform channels. Existe un paquete de comunidad, flutter_carplay, que envuelve buena parte de esa fontanería y te deja orquestar las plantillas desde Dart, con cobertura también para Android Auto. Cubre las plantillas más habituales y le faltan otras; al ser mantenido por la comunidad, revisa su estado actual y su ritmo de versiones antes de apoyar un proyecto entero en él. Si necesitas ir más allá de lo que ofrece, el camino es el de siempre: interop nativo y una capa fina de plantillas por plataforma sobre tu núcleo compartido.
La arquitectura que funciona es esa: un core en Dart, dos superficies de coche delgadas y nativas colgando de él. No un segundo proyecto.
Cuándo NO tiene sentido llevarla al coche
Lo decimos con la misma claridad con la que lo hablamos con un cliente antes de empezar.
Si tu caso de uso no cae en una categoría aprobada, no hay nada que hacer. Una app de banca, de retail o de gestión interna no entra en el coche porque Apple y Google no abren esa puerta, y prometérselo a alguien es venderle humo. Comprueba la categoría antes que cualquier otra cosa.
Si entras pero tu valor depende de una interfaz rica, el coche tampoco es el sitio. La experiencia tiene que reducirse a tres o cuatro tareas que alguien pueda resolver de un vistazo con las manos en el volante. Lo demás sobra y, de hecho, no te lo van a aprobar.
Y aunque encajes, cuenta el coste real. Es una superficie más que mantener, nativa, con su revisión de Apple y su aprobación de entitlement por medio. Si lo único que buscas es poder decir que tu app «ya está en el coche», ese brillo no paga la factura. Hazlo cuando la tarea en movilidad sea genuina: encontrar y arrancar una recarga, seguir una ruta de reparto, controlar el audio.
Decisión rápida
| CarPlay | Android Auto | |
|---|---|---|
| Modelo de UI | Plantillas cerradas de Apple | Plantillas cerradas de Google |
| Requisito de acceso | Entitlement por categoría, solicitado a Apple | Categoría aprobada + nivel de API declarado |
| Categorías típicas | Audio, navegación, carga de VE, aparcamiento, mensajería, voz | Navegación, puntos de interés (carga, parking), IoT, meteorología |
| Lienzo libre | Solo navegación | Solo navegación |
| Qué aporta Flutter | Lógica y datos en Dart; UI nativa por plantillas | Igual: núcleo compartido, plantillas nativas |
| Distribución | App Store, con el entitlement concedido | Android Auto o Automotive OS, según el objetivo |
En resumen
Si trabajas en movilidad, recarga, audio o navegación, la pantalla del coche está a tu alcance y tu núcleo Flutter se reutiliza casi entero. Presupuesta la capa nativa de plantillas y la espera del permiso, y diseña para tres tareas, no para treinta. Si no estás en ninguna de esas categorías, «llevar la app al coche» es el objetivo equivocado, y lo útil es decirlo pronto.
En Dribba llevamos desde 2011 construyendo apps en Flutter con equipo senior propio, incluidas las de recarga de vehículo eléctrico y reparto en movilidad. Si estás valorando si tu producto tiene un sitio real en CarPlay o Android Auto, un discovery corto te ahorra meses de trabajo mal enfocado. Hablamos.
