LiveCharts2: one charting API across WPF, Avalonia, MAUI and Blazor
Beautiful, interactive charts, maps, and gauges. One API for every .NET UI framework.
At a glance
- What is it?
- LiveCharts2 is the second generation of the LiveCharts .NET charting library, rebuilt so the same chart definitions run on ten UI frameworks. It installs from NuGet per platform, and the real cost is in the platform-specific setup, not the drawing code.
- Who is it for?
- Adopt LiveCharts2 when you maintain charts on more than one .NET UI stack and want a single chart definition to serve all of them, or when you need server-side rendering through the core packages alone. Skip it if your charting is confined to a single mature WPF screen where a WPF-native control already works, or if you need the library to draw your UI itself, since the README states it does not own the rendering surface.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 72 days ago.
- What is it written in?
- Mainly C#, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 30, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The problem LiveCharts2 was written to fix
LiveCharts2 exists because its predecessor was welded to WPF. The README says v0 "is built on top of WPF, which has many limitations", and that when the maintainers tried to bring v0 to UWP the architecture made it a huge effort. That is the problem statement: a charting library whose drawing and layout assumptions are inherited from one desktop framework cannot be moved to Maui, Avalonia, Blazor or the server without a rewrite.
So the target audience is .NET teams that ship the same product surface on more than one UI stack. If you maintain a WPF desktop app and an Avalonia or MAUI build of the same tool, you currently either write the chart code twice or keep two charting dependencies with different APIs. LiveCharts2's pitch is one API for every framework it lists: Maui, Uno Platform, Wpf, WinUI, Xamarin.Forms, WindowsForms, BlazorWasm, Avalonia, Eto Forms and Uwp. A second audience is server-side and console code, where the README points to installing only the core packages to build a chart image without any UI framework at all.
The trade-off is visible in the repository layout. There is not one solution file but eight: LiveCharts.WPF.slnx, LiveCharts.Avalonia.slnx, LiveCharts.Maui.slnx, LiveCharts.Uno.slnx, LiveCharts.Blazor.slnx, LiveCharts.WinForms.slnx, LiveCharts.WinUI.slnx and LiveCharts.Tests.slnx, plus a LiveCharts.slnx at the root. Cross-platform reach is bought with per-platform build and packaging surface, and that surface is what you inherit when you adopt it.
How the drawing layer separates from the UI framework
The README is explicit that SkiaSharp is the current drawing engine but not a hard requirement: "The Skia API makes it much easier to take the library everywhere, but that does not mean that LiveCharts2 requires it to work. We could easily move to any other drawing engine." That sentence is the architectural claim worth checking, because it implies the chart model is not expressed in Skia types.
The samples directory backs this up. Alongside the per-framework sample projects (samples/WPFSample, samples/AvaloniaSample, samples/MauiSample, samples/BlazorSample, samples/UnoPlatformSample, samples/WinUISample, samples/WinFormsSample, samples/EtoFormsSample) there is samples/ViewModelsSamples, which is not tied to any of them. The pattern the repository is built around is that chart definitions live in shared view models, and each platform sample only hosts them. If you are evaluating the library, that shared folder is the most informative part of the tree: it tells you how much of a chart is framework-agnostic and how much is glue.
Two other sample projects show the boundary of the design. samples/ConsoleSample and samples/ConsoleEngineSample use the core packages with no UI framework, and samples/QuestPDFSample and samples/VorticeSample show the library in contexts that are not UI toolkits at all. The README links a guide for building a chart image server-side, which is the same idea in documentation form. What the repository does not show is a formal plugin interface for swapping the renderer. The README asserts the move is possible; the code does not document the contract you would implement to do it.
Installing LiveCharts2 and drawing a first chart
The README does not list package names or versions. It says to go to https://livecharts.dev and follow the installation guide for your target platform, and that the site contains the samples from this repo plus documentation. The NuGet package LiveChartsCore is named in the repository's own README badge, and the samples carry a samples/NuGet.config, so package resolution is part of the sample setup. Treat the website as the source of truth for the exact package for your framework at version 2.0.4.
The general shape of a first use is: add the platform package for your UI framework, reference the core package, then define a chart in a view model and bind it in the view. The repository's shared view models live under samples/ViewModelsSamples, and the per-framework sample projects show the hosting code for each. The README gives no install command of its own, so the first step is the installation page for your platform rather than a command copied from here.
After restoring, the samples/NuGet.config file in the repository shows how the sample projects resolve their feeds, which is useful if you are behind a private feed. The samples/AvaloniaSample, samples/BlazorSample, samples/MauiSample, samples/WPFSample and samples/WinUISample directories each hold the hosting code for their framework, and those files are the closest thing to a worked example that the repository provides.
For a console or server scenario the README points to a specific guide rather than a sample command, so the honest instruction is to open that page before writing code. What you should see after a correct setup is a chart rendered into an image or a control, depending on which of the two paths you took. If nothing renders, the most likely cause is a missing platform package rather than a mistake in the chart definition, since the definition itself is framework-independent.
Where LiveCharts2 stops being the right tool
The library draws charts, not applications. The README's framing is a data visualization library, and the samples are chart and gauge samples, so if you need a full dashboard framework with routing, theming and data sources, LiveCharts2 is one component inside that, not a substitute for it.
The second limitation is the SkiaSharp dependency in practice. The README argues the dependency is not fundamental, but every platform package in the tree is built on the Skia-backed view layer, and the samples that render off-screen lean on it too. On a platform where SkiaSharp is awkward to deploy, you are relying on a design claim rather than a documented alternative renderer.
The third is the documentation gap on failure modes. The README does not document rollback, does not list known limitations per platform, and does not describe what happens when a chart is hosted in a control that resizes aggressively or is virtualized. The repository has a tests/ directory and a LiveCharts.Tests.slnx, and the README badge reports line coverage, but coverage numbers are not a statement about rendering behaviour under load. If your requirement is a chart that must survive a hostile layout, you will be finding that out yourself.
Finally, the README still describes v2 as beta in the preview section, even though 2.0.0 shipped on 2026-04-01 and 2.0.4 on 2026-05-16. That line is stale relative to the release list, and it is a reminder that the README lags the code.
LiveCharts2 against OxyPlot and ScottPlot
The two comparisons people search for are OxyPlot and ScottPlot, and the difference is not feature lists, it is what each library assumes about your UI.
OxyPlot has historically been the conservative choice for .NET plotting: a mature, widely ported plotting library with its own rendering abstractions and a long track record on WPF and Xamarin. The practical difference with LiveCharts2 is the API surface. LiveCharts2 exposes chart, series and axis definitions that the same code can host on ten frameworks, and it ships shared view models in the repository to make that concrete. If you are already on OxyPlot and it works, the reason to move is cross-framework reach, not plotting capability.
ScottPlot takes a different route again: it is oriented around plotting data quickly, including large series, and its API is closer to a plotting call than to a declarative chart object. The searches pairing ScottPlot and LiveCharts2 usually come from people weighing interactive, animated charts against fast static plotting. LiveCharts2's README emphasizes flexibility and running everywhere; it makes no performance claim, and you should not read one into it. The repository does not publish benchmark numbers, so any performance comparison you find elsewhere is not something this project's own documentation supports.
The honest summary: LiveCharts2 competes on portability and on being one API across frameworks. If your requirement is raw plotting throughput on a single platform, that is not the axis this library is documented around.
Maintenance, licensing and what upgrading costs
The repository is not archived, and the last push was on 2026-07-20. Releases are 2.0.4 on 2026-05-16, 2.0.0 on 2026-04-01, and v2.0.0-rc6 on 2025-09-12. The gap between rc6 and the stable release is roughly seven months, which tells you the 2.0 line took a while to settle after the release candidate stage.
The upgrade cost is structural rather than incidental. Because there are separate solution files per UI framework, a version bump means the platform package, the core package and the shared view model code all move together, and the samples for your framework are the reference for what changed. The README also states v2 "fixes the main design issues of its predecessor", which means v0 to v2 is a migration, not a drop-in upgrade. If you are on v0, budget for rewriting chart definitions rather than adjusting them.
Licensing is MIT, stated in the repository root as LICENSE. That is permissive and imposes no source disclosure on your application. It says nothing about the licences of your dependencies, and SkiaSharp is a dependency of the view layer, so its terms apply to your build independently. This is a description of the licence file, not legal advice; if your organisation has a policy on transitive dependencies, check them separately.
Editorial conclusion
Adopt LiveCharts2 when you maintain charts on more than one .NET UI stack and want a single chart definition to serve all of them, or when you need server-side rendering through the core packages alone. Skip it if your charting is confined to a single mature WPF screen where a WPF-native control already works, or if you need the library to draw your UI itself, since the README states it does not own the rendering surface. Before committing, open the installation page for your target platform at livecharts.dev, confirm the package names and versions that page lists for 2.0.4, and check whether your render target can host a SkiaSharp canvas.
Frequently asked questions
How do I use LiveCharts2 in a WPF application?
Install the platform package for WPF plus the core packages, then define the chart in a view model and host it in the view. The repository keeps the shared chart definitions under samples/ViewModelsSamples and the WPF hosting code under samples/WPFSample, and the README directs you to the installation guide at livecharts.dev for the exact package.
What is the difference between LiveCharts and LiveCharts2?
LiveCharts2 is described in the README as the evolution of LiveCharts v0, fixing v0's main design issues. V0 was built on top of WPF, which the README says limited the library, while v2 is designed to run on multiple platforms with minimal effort to add a new one.
Which UI frameworks does LiveCharts2 support?
The README lists Maui, Uno Platform, Wpf, WinUI, Xamarin.Forms, WindowsForms, BlazorWasm, Avalonia, Eto Forms and Uwp. It also states you can use it in a console app or on the server side by installing only the core packages.
Does LiveCharts2 require SkiaSharp?
Not necessarily, according to the README. It says the Skia API makes it much easier to take the library everywhere but that LiveCharts2 does not require it to work, and that the drawing engine could be changed. In practice the platform packages in the repository are built on the Skia-backed view layer.
Is LiveCharts2 free to use in a commercial application?
The repository is licensed under MIT, which is permissive and does not require you to disclose your application source. That covers LiveCharts2 itself; dependencies such as SkiaSharp carry their own terms.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/live-charts-livecharts2)