Microcharts: cross-platform .NET charts built on SkiaSharp with a deliberate simplicity ceiling

Microcharts is intentionally minimal: fork it if you need more control

Microcharts provides chart rendering for .NET by calling SkiaSharp drawing APIs. The design ceiling is explicit: customization beyond what the library provides is not supported through configuration. Forking the source is the documented path for teams that need custom rendering behavior.

That ceiling is a trade-off with real implications. A team whose charts fit the default behavior gets a library that is straightforward to add and maintain. A team that needs different axis behavior, custom tooltip rendering, or chart types outside the provided set faces a fork decision at the start rather than a configuration exercise. Teams needing customization fork the source; the codebase is small enough to make that practical.

All rendering goes through SkiaSharp, a .NET binding to Google's Skia graphics library. Using a single rendering layer means chart output is visually consistent across MAUI, iOS, and Android, but it also means anything Skia cannot express is unavailable to chart authors.

Three packages are on nuget.org, but native iOS and Android views need a GitHub token

Five packages cover different integration paths. Three are on nuget.org: Microcharts is the meta-package and the starting point, Microcharts.Core provides cross-platform rendering, and Microcharts.Maui supplies the ChartView control for MAUI applications. Standard NuGet tooling installs all three without additional source configuration.

The remaining two packages, Microcharts.iOS and Microcharts.Droid, are published to the GitHub Packages feed for the microcharts-dotnet organization rather than to nuget.org. Installing them requires adding that organization's feed as a NuGet source and authenticating with a GitHub personal access token that has the read:packages scope.

This package split has a real impact on pipeline setup. The nuget.org packages restore in any standard pipeline without credentials. The GitHub Packages packages do not: pipelines building iOS or Android projects with the native views need the token as a secret and the org feed registered in nuget.config. That requirement is stated without an example nuget.config or CI configuration snippet.

MAUI projects need UseMicrocharts() on MauiAppBuilder, and iOS and Android do not

For MAUI applications, there is one required initialization step: call `UseMicrocharts()` on `MauiAppBuilder` in the `MauiProgram` class. No corresponding initialization call is documented for the native .NET for iOS or .NET for Android views, so the MAUI path has a distinct setup requirement the native paths do not share.

What happens when `UseMicrocharts()` is omitted is not documented. In .NET MAUI, initialization calls on the builder register controls and handlers; skipping them prevents the view from rendering or causes a runtime error. The README does not document the failure mode, so a missing call would need to be identified through the error at runtime.

For a MAUI project starting from scratch, the minimum documented path is: install the Microcharts meta-package from nuget.org, add the builder call to MauiProgram, and consult the wiki for chart type and data binding APIs.

SkiaSharp handles all drawing, and the library adds no abstractions above what Skia provides

Microcharts calls SkiaSharp drawing APIs directly. There is no intermediate abstraction layer between chart data and the rendered output. That decision keeps the library small and means that anyone reading the source finds SkiaSharp calls rather than a custom drawing framework.

For most MAUI and mobile projects, SkiaSharp is already a dependency through other libraries, so adding Microcharts does not introduce a new package dependency. For projects without SkiaSharp, both SkiaSharp and its native Skia binaries come in as transitive dependencies. Binary size impact from adding SkiaSharp to a project that did not previously use it is not documented in the README.

Chart output is defined by what SkiaSharp can express. Colors, gradients, line weights, and typefaces all go through SkiaSharp's canvas API. If a chart design requires something SkiaSharp cannot draw, the only path is to modify the drawing calls in the source.

The repository topics include UWP and Xamarin, but the compatibility section lists only .NET 10 targets

The repository topics list seven items: android, charts, graphics, ios, skia, uwp, and xamarin. A team searching for .NET chart libraries by platform might find this repository through the uwp or xamarin tags.

The compatibility section in the README lists only three platforms, all on .NET 10: .NET MAUI (covering Windows, Android, iOS and Mac Catalyst), .NET for iOS, and .NET for Android. UWP is absent from the compatibility section. Xamarin does not appear there either. The one tutorial listed is for Xamarin.Forms and carries a note that it is legacy, with charting concepts that still apply but the framework no longer current.

Those repository topics were accurate at an earlier point in the project's history and have not been updated to match the current scope. A team on UWP or Xamarin checking the compatibility section would find no confirmed support for their platform.

Microcharts compared to OxyPlot and a direct SkiaSharp implementation

Three options cover most cross-platform .NET charting needs: Microcharts, OxyPlot, and writing chart rendering directly on SkiaSharp. Each fits a different point on the control-versus-effort axis.

OxyPlot provides a broader set of chart types, explicit axis configuration, and a model-view pattern that gives more control over chart appearance. That flexibility comes with more setup: axis, series, and model objects need explicit configuration before a chart renders. Microcharts removes those decisions from calling code by keeping the configurable surface small. For a project that needs only line, bar, or point charts and no custom styling, Microcharts reaches working code faster than OxyPlot.

A direct SkiaSharp implementation gives complete control over every rendering decision and no overhead from a chart library. It also requires writing and maintaining all chart math and drawing logic. Microcharts sits between these options: it removes the drawing work while accepting a fixed ceiling on what that drawing can produce.

Chart types, data APIs and animations are documented in the wiki, not in the README

Packages, setup, and compatibility are documented inline. Chart types, the data model, axis configuration, and animation details are in the wiki at github.com/microcharts-dotnet/Microcharts/wiki. A team deciding whether to adopt Microcharts cannot determine supported chart types from the README alone. A gallery shows chart output visually, but names and configuration options for those chart types are not listed inline.

For a team adopting Microcharts, the wiki is where the chart type API lives. The README covers enough to get the first chart rendering but not enough to evaluate the full set of available chart types or configure data entries. Reading the wiki before starting a project avoids discovering missing chart types or data model constraints partway through integration.

Release 2.0.0.3, labeled .NET 10 + MAUI, arrived on 2026-07-21 and the last push was on 2026-09-18. The library is distributed under the MIT license.

Editorial conclusion

Use Microcharts when your .NET MAUI, iOS, or Android project needs charts and the default visual output matches your requirements. Skip it when you need custom renderers, highly configurable axes, or chart types beyond what its gallery shows, since forking is the documented path for customization rather than a configuration API. Before starting, check the wiki at github.com/microcharts-dotnet/Microcharts/wiki for the chart type API, and confirm your CI environment can authenticate against the GitHub Packages feed if you need the native Microcharts.iOS or Microcharts.Droid packages.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. microcharts-dotnet/Microcharts on GitHub
4. README
5. Releases