MPAndroidChart 4.0 is a Kotlin rewrite on new coordinates, and 3.x is still shipping

The 4.0 coordinates differ, so a 3.x project keeps building untouched

4.0 is a rewrite in Kotlin and its coordinates differ from 3.x, which is precisely why a project sitting on com.github.PhilJay:MPAndroidChart keeps building without a single change. The new coordinates are scoped differently and split across two artifacts, one for the view library and one for Compose. The release history makes the split explicit: v3.2.0 and v4.0.0 were both published on 2026-09-26, v4.0.1 followed on 2026-09-28, and the last push to the default branch is dated 2026-09-26. So this is not a library where the old line has been frozen and the new one has taken over. Both are moving, on separate coordinate sets, and choosing one is a decision about which line you mean to be on rather than a temporary bridge. Arriving from the Java 3.x versions, the repository points you at MIGRATION.md and a longer migration guide, with CHANGELOG.md covering what changed in 4.0.

JitPack is the only repository in the install and there is no Central fallback

The dependency does not arrive from Maven Central. The install snippet adds a JitPack repository under dependencyResolutionManagement in settings.gradle.kts, then declares two implementation lines against com.github.PhilJay.MPAndroidChart, MPChartLib for the view library and MPChartCompose, the second commented as being only for Compose. A jitpack.yml file sits at the repository root and JitPack is named in the acknowledgements. Three consequences follow for a build. Your dependency graph now points at a third-party service, so a corporate build with a repository allowlist has to be amended before anything resolves. Every resolve has to reach that service rather than pulling a prebuilt artifact from a registry you already mirror. And because the coordinates carry a version tag, what you get is tied to a specific tagged revision rather than to a moving branch.

// settings.gradle.kts
dependencyResolutionManagement {
    repositories {
        maven("https://jitpack.io")
    }
}

// build.gradle.kts
dependencies {
    implementation("com.github.PhilJay.MPAndroidChart:MPChartLib:v4.0.1")
    implementation("com.github.PhilJay.MPAndroidChart:MPChartCompose:v4.0.1") // only for Compose
}

minSdk 23, Java 17, and compileSdk 37 the moment Compose enters

The stated requirements are minSdk 23, compileSdk 35, Java 17, and Kotlin 2.0 or newer. The Compose module then adds a condition that catches people out: it needs compileSdk 37, because Compose itself does. The number you are told to compile against therefore jumps by two the moment you add a chart to a Compose screen, and there is no configuration in which the Compose module works at 35. Two of the other numbers are hard floors as well. Devices below API 23 are out of scope, and Java 17 rules out any build still on an older toolchain, which means a project can keep compiling happily on 3.x long after moving to 4.0 has become impossible. The single number that is not a constraint is Kotlin, since Java callers need no Kotlin at all even though the library itself was rewritten in Kotlin.

val entries = listOf(Entry(0f, 4f), Entry(1f, 8f), Entry(2f, 6f))
val set = LineDataSet(entries, "Sales").apply {
    color = Color.BLUE
    lineWidth = 2f
    mode = LineDataSet.Mode.CUBIC_BEZIER
}
chart.data = LineData(set)
chart.animateX(500)

setup runs once, and nothing runs it a second time for you

In the Compose path every chart type has a composable of the same name, you pass data as state, configure the view inside a setup block, and read selection and viewport back through the state object. That block carries one rule that decides a lot of debugging time: setup runs once. Anything you compute from changing state inside it is applied to the first composition and then never again, so when a user switches theme, changes locale, or picks a range, your configuration is stale until you reapply it imperatively or drive it from a separate effect. The reactive half lives in the state object, which exposes selectedEntry, the visible range, and the zoom, and offers highlight, zoomIn, fitScreen, moveViewToX, and the animate functions. The sample sets two booleans, description.isEnabled and axisRight.isEnabled, which look harmless until one of them has to follow app state.

val state = rememberChartState()
LaunchedEffect(lineData) { state.animateX(500) }

LineChart(
    data = lineData,
    modifier = Modifier.fillMaxWidth().height(300.dp),
    state = state,
    marker = { entry, _ -> Text("${entry.y}") },
    setup = {
        description.isEnabled = false
        axisRight.isEnabled = false
    },
)

Two surfaces for the same library, with no stated feature parity

There are two ways to drive the same charts and the documentation treats them as parallel tracks. The View path configures a chart through properties and takes lambdas for formatters and listeners, including an IAxisValueFormatter that turns an axis value into a month name and an onValueSelected callback that hands you the chosen entry. The Compose path uses a state object, a setup block, and a marker slot. What is not stated anywhere is which View capabilities have a Compose equivalent, so porting an existing chart means discovering the gap screen by screen rather than reading a mapping. The Compose chapter is said to cover state, markers, previews, and the colour and typeface helpers, which is an inventory of what exists rather than a translation table from the View API. Check the specific capability your screen depends on before committing that screen to the Compose path.

The install section tells you to pin rather than track the newest tag

One instruction in the install section inverts the usual advice and is worth repeating: pin the version, do not track the newest one. In a repository publishing at this pace that is not a casual remark. The recent tags are v4.0.0 and v4.0.1 two days apart, v3.2.0 on the same day as v4.0.0, and the default branch was pushed on 2026-09-26. A build that resolves whatever is newest will pick up a new major or a new artifact coordinate without a decision from you, and with two live coordinate sets the risk of landing on the wrong one is concrete rather than theoretical. If you take the library from JitPack, treat the version string as part of your own build configuration and change it deliberately, reading CHANGELOG.md for the 4.0 changes at the moment you do.

Usage questions go to Stack Overflow, and funding goes to one person

Support is split three ways, and the split tells you the shape of the project. The issue tracker is for bugs and feature requests, while usage questions are directed to Stack Overflow under the mpandroidchart tag, which means a how-do-I question filed as an issue is in the wrong place by the project's own definition. Funding is entirely personal: rate the author's other apps, sponsor on GitHub, or donate through PayPal, and the apps in question are the author's own, one of them a macOS screenshot and screen recording tool. The library is Apache-2.0, with the full text in LICENSE, the attribution in NOTICE, and copyright running 2014 to 2026 Philipp Jahoda, so the licence places no obligation on you whatsoever. That is not the question to weigh. What is worth weighing when a chart library sits on a product surface is that all of it runs through one maintainer.

An entry can carry your own object and get it back typed

Entries are not limited to coordinates. An entry can be constructed with your own object, and when you do, the entry becomes generic over that type, so the payload comes back typed from lookups and selections rather than as an untyped value you cast at every call site. That pays off in exactly the places charts get awkward: a tooltip that needs the order behind a point, a selection handler that needs a record id, a marker that needs a label from your own domain rather than a formatted number. The cost is that the type parameter belongs to the data set. A set whose entries carry different payload types has no single type to name, so mixed payloads push you back to leaving data unset and downcasting later, which is the arrangement you were trying to leave behind. Choose the payload type before you build the data set rather than after the first awkward cast.

Editorial conclusion

MPAndroidChart 4.0 is the version to start on if you are building an Android chart today, because both the old Java line and the new Kotlin line are still receiving releases and you would rather not begin on the one marked for migration. Take it only if you can move to Java 17, add compileSdk 37 for Compose, and let your build resolve from JitPack. Before upgrading a 3.x project, read MIGRATION.md, since the coordinates change and the rewrite is in Kotlin even though Java callers need no Kotlin at all. Pin v4.0.1 rather than tracking the newest tag, which is the project's own instruction.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes