Un caso real: migrar el sistema de charts de PiggyBank descubrió que el README nunca cuenta toda la historia — y que evaluar KMP a mano no escala.
No es falta de librerías — es falta de visibilidad. ¿Soporta iOS de verdad o solo declara el target? ¿Está mantenida? ¿Qué tan real es esa feature que promete el README?
kotlinm-charts: una lib propia (carlosgub/kotlinm-charts) usada en producción para los bar & line charts de la app. Migrar el resto del stack a Kotlin 2.4 / Compose 1.12 era el momento perfecto para probar si klibs.io encontraba algo mejor.
Gasto diario por mes, con overlay táctil mostrando el monto exacto del día tocado — una feature real, no decorativa.
Mismo soporte Android + iOS, mejor mantenimiento, sin perder la interacción táctil que ya usa la app.
Todos con bar chart + line chart, todos publicados en Maven Central. En superficie, se ven casi idénticos.
| Librería | Stars | Plataformas | Notas |
|---|---|---|---|
| HDCharts | 454 ★ | Android + iOS | Interacción táctil real, docs completas |
| AAY-chart | 681 ★ | Android + iOS | Más popular — sin gestos de selección |
| compose-multiplatform-chart | 7 ★ | Android + iOS | Nicho, pensado para datasets grandes |
| kmpcharts | 1 ★ | Android + iOS | Muy joven, tooltip documentado en README |
Ningún README menciona si el tap-to-select realmente existe. Solo clonando el código fuente se puede confirmar.
Sin detectTapGestures, sin pointerInput en LineChart.kt ni BarChart.kt. La lib más popular del catálogo no tiene selección táctil.
BarChartInteractionModifiers.kt, selectedBarIndex, tap+drag+pinch reales. El callback onValueChanged existe — pero nunca se expone en la función pública BarChart().
Con HDCharts elegido por su interacción real, quedaban tres caminos honestos sobre la mesa:
El valor tocado reemplaza el título interno del chart — funcional, pero no es tu diseño.
El bar chart queda visual, sin tooltip al tocar. Honesto sobre lo que la librería puede dar hoy.
Cero regresión, pero dos librerías de charts conviviendo en la misma app.
Con minBarWidth y space por defecto (10.dp cada uno), HDCharts no encontraba espacio para 31 días y activaba su modo denso — un toggle "[+]" sin estilo, que nunca existió en el diseño original.
El header muestra un [+] negro flotando sobre el fondo azul — ningún diseño lo contemplaba.
Con minBarWidth = 3.dp y space = 1.dp, las 31 barras caben sin activar el modo denso.
// dispara modo denso con 31 días BarChartDefaults.style( barColor = barColor, yAxisLabelsVisible = withYChart, zoomControlsVisible = false, selectionLineVisible = false, )
BarChartDefaults.style( barColor = barColor, yAxisLabelsVisible = withYChart, zoomControlsVisible = false, selectionLineVisible = false, space = 1.dp, minBarWidth = 3.dp, )
Compose Multiplatform puro: el mismo commonMain renderiza igual en ambas plataformas vía Skia. Pero esto todavía no es el final de la historia.
Dos tools, MCP Kotlin SDK, corriendo por stdio. Nada de scraping — consulta GitHub y Maven Central directo, la misma verificación que hicimos a mano pero automatizada.
bytebeats/compose-charts-desktop (34★) Tweener/chartopia (26★) carlosgub/kotlinm-charts (23★) Jeremy-Gitau/multiplot (4★) // tu propia lib, encontrada por el mismo tool... // ...pero algo importante falta en esta lista
io.github.dautovicharis:charts:2.4.0 (latest of 9 published versions last updated 2026-08-01) // el índice Solr de Maven Central mostraba // solo 2 de las 9 versiones -- tuvimos que // leer maven-metadata.xml directo para confiar en el dato
Esa fue la pregunta que destapó todo. Mi propia tool tenía el mismo problema que vinimos a resolver: un filtro rígido topic:kotlin-multiplatform excluía librerías reales que se etiquetan distinto.
No usa el topic exacto kotlin-multiplatform — el filtro la descartaba entera.
Ninguna variante de "multiplatform" ni "kmp" — la librería que terminamos usando, invisible para mi propio tool.
Y sobre kotlinm-charts: klibs.io exige "at least one artifact published to Maven Central" — tu lib vive en GitHub Packages, así que estructuralmente nunca podría entrar al catálogo.
Reemplazar topic:kotlin-multiplatform por una búsqueda de texto libre en name/description/topics cambió todo el resultado:
| Librería | Stars | Nota |
|---|---|---|
| patrykandpatrick/vico | 3158 ★ | Invisible hasta arreglar el filtro |
| KoalaPlot/koalaplot-core | 782 ★ | Tampoco aparecía antes |
| TheChance101/AAY-chart | 681 ★ | Recuperada |
| HDCharts/charts | 454 ★ | Recuperada — la que ya habíamos migrado |
CartesianMarkerVisibilityListener expone onShown(marker, targets) con el valor real tocado. HDCharts tenía el mismo concepto, pero nunca lo exponía fuera de la librería.
CartesianValueFormatter.decimal(prefix = "$") sí llega al eje Y. HDCharts tenía una API idéntica en el papel, pero jamás estaba cableada a nada.
Confirmado en su build.gradle.kts — y usa el mismo plugin com.android.kotlin.multiplatform.library al que ya habíamos migrado PiggyBank.
Vico no es solo más popular — el fix del bug fue lo único que nos dejó verlo.
Con el callback público de Vico, el onOverlayData custom de PiggyBank volvió intacto — algo que HDCharts nunca hubiera permitido.
La librería más popular en un momento dado (681★) no tenía la interacción que sí tenía otra con menos estrellas. El ranking por popularidad no responde la pregunta real.
Confirmar "¿soporta tap-to-select de verdad?" tomó clonar repos y leer código interno — ninguna búsqueda de README lo hubiera resuelto.
Un filtro rígido en klibs-mcp casi nos hace repetir el error de confiar en poca evidencia — y nos escondió la mejor opción del catálogo.
Es un catálogo web sin API pública, y solo indexa lo publicado en Maven Central. Automatizar esta verificación significó construir la pieza que falta nosotros mismos.
El caso completo — migración, hallazgos, MCP server y código — está en los repos.