Al planificar el mapa de Caladero tuve que decidir entre dos caminos técnicos bastante distintos: usar el SDK de Google Maps para Android, o usar MapLibre, una alternativa de código abierto nacida como fork de Mapbox GL. No es una decisión que se pueda resolver con un titular tipo "usa siempre X"; depende de qué necesita la app en concreto, de qué control quiero tener sobre el estilo del mapa y de las condiciones de uso de cada plataforma, que conviene revisar en la documentación oficial de cada una en vez de dar por hecho cifras o límites concretos.
Qué es cada opción, sin entrar en marketing
Google Maps SDK para Android es la integración oficial de Google para mostrar mapas basados en su plataforma, con acceso a su base de datos cartográfica, imágenes de satélite, y servicios asociados como geocodificación o rutas. Es el más conocido y probablemente el que más usuarios reconocen visualmente por su estilo característico.
MapLibre es un proyecto de código abierto, mantenido por la comunidad, que permite renderizar mapas vectoriales con estilos personalizables, y que puede alimentarse de distintas fuentes de datos de teselas, no solo de un proveedor concreto. No está atado a un servicio comercial único: se puede combinar con datos de OpenStreetMap, con proveedores comerciales de teselas, o con un servidor propio de teselas si el proyecto lo requiere.
El criterio que más peso tiene para mí: control sobre el estilo y la fuente de datos
En Caladero, quería un estilo de mapa relativamente sobrio, con énfasis en elementos de agua (ríos, embalses, costa), que no siempre coincide con el estilo por defecto de un mapa generalista pensado para navegación de carretera. Con MapLibre, el estilo del mapa se define mediante una especificación de estilo en JSON que se puede personalizar con bastante libertad: qué capas se muestran, con qué colores, qué elementos se resaltan. Con Google Maps, la personalización de estilo también existe, pero está más acotada a lo que el propio SDK permite configurar mediante su sistema de estilos.
Esa libertad de MapLibre tiene una contrapartida: hay que encargarse de elegir y, en muchos casos, mantener la fuente de datos de teselas, mientras que con Google Maps esa parte viene resuelta de fábrica como parte del servicio.
Un ejemplo práctico de integración con MapLibre
La integración básica de un mapa con MapLibre en una app Android con Compose se apoya en la librería maplibre-compose o en la vista clásica de MapLibre embebida mediante interoperabilidad con AndroidView, dependiendo de la versión y el enfoque elegido. A grandes rasgos, el flujo es:
MapView(context).apply {
getMapAsync { mapLibreMap ->
mapLibreMap.setStyle("https://mi-servidor-de-estilos.example/estilo.json") {
mapLibreMap.addMarker(
MarkerOptions()
.position(LatLng(punto.latitud, punto.longitud))
.title(punto.nombre)
)
}
}
}
La diferencia clave frente a Google Maps es que aquí decido explícitamente de dónde viene el estilo y las teselas del mapa: puede ser un servidor propio, un proveedor de teselas de terceros compatible con el estándar de estilos vectoriales, o datos derivados de OpenStreetMap servidos por algún proveedor. Esa decisión no es trivial y tiene sus propias implicaciones de coste y mantenimiento, que dependen del proveedor de teselas elegido, no de MapLibre en sí.
Sobre costes y límites de uso: consulto siempre la fuente oficial
No voy a dar aquí cifras concretas de precios ni de cuotas gratuitas de ningún servicio, porque las condiciones de uso y los límites de facturación cambian con el tiempo y varían según el tipo de uso (número de cargas de mapa, tipo de API usada, volumen de peticiones). Si esta decisión depende para ti de cuánto va a costar a partir de cierto volumen de uso, lo correcto es consultar directamente la documentación oficial vigente de Google Cloud sobre el SDK de Google Maps para Android y las condiciones asociadas a la clave de API, en vez de fiarte de una cifra que alguien escribió en un artículo y que puede haber quedado desactualizada.
Con MapLibre, al ser el software en sí de código abierto y sin coste de licencia, el coste real depende exclusivamente del proveedor de teselas que se elija para servir el mapa, si se decide usar uno comercial, o del coste de infraestructura propia si se opta por alojar las teselas uno mismo. Ese coste hay que evaluarlo caso por caso con el proveedor concreto, no como una característica de MapLibre en sí.
Cuándo elegiría Google Maps en vez de MapLibre
Si la app necesita funcionalidades muy integradas con el ecosistema de Google, como Street View, datos de tráfico en tiempo real, o una experiencia de navegación muy similar a la que los usuarios ya conocen de Google Maps, tiene sentido usar el SDK oficial directamente, porque replicar esas funcionalidades con MapLibre requeriría integraciones adicionales que Google ya resuelve de forma nativa. Para Caladero, ninguna de esas funcionalidades es relevante: no necesito Street View ni datos de tráfico, así que ese argumento no aplicaba en mi caso.
Errores y límites que he encontrado con MapLibre
El primer ajuste que tuve que hacer fue entender que, al no depender de un proveedor único integrado, la responsabilidad de que el mapa cargue rápido y de forma fiable recae más en mí: elegir un proveedor de teselas con buen rendimiento, configurar correctamente la caché de teselas en el dispositivo, y probar el comportamiento con conexión lenta o intermitente, algo que conecta directamente con el enfoque local-first que sigo en el resto de la app.
Otro límite real es la documentación y la comunidad: al ser un proyecto de código abierto con menos recursos que un producto comercial de una gran empresa, algunas dudas concretas de integración tardan más en encontrar respuesta en foros o en la documentación oficial del propio proyecto, comparado con la cantidad de ejemplos y respuestas disponibles para el SDK de Google Maps.
Conclusión
No hay una respuesta única correcta entre MapLibre y Google Maps; depende de cuánto control se necesite sobre el estilo visual y la fuente de datos, de si hacen falta funcionalidades específicas del ecosistema de Google, y de un análisis de coste que solo se puede hacer bien consultando las condiciones oficiales vigentes de cada proveedor implicado, no cifras aproximadas de terceros. En mi caso, para Caladero, el control sobre el estilo y la independencia de un único proveedor comercial pesaron más que la comodidad de una integración todo en uno, pero entiendo perfectamente que en otros proyectos la balanza se incline al revés.