Last year, I had reviewed some chart packages which allow to draw multiple chart types. Last month, I picked up the note I marked down about the chart packages for my latest personal project. It seems things have changed a lots this year.
Drawing chart on Flutter app basically has two approaches — native painting and embedding third party js chart library webview. Normally, we may have an impression that using webview to do the rendering may have relatively lower performance than that of native rendering. The reason why we may consider the js library because at the beginning there has very few options on chart packages with native drawing and only some basic line or bar chart are supported. However, many js chart libraries are already in a mature release. At this time, embedding webview with js chart library is the fastest way to obtain what we want. Since last year, more and more mature native chart packages published, we now have more options on charting package selection.
In spite of types, charting feature support like customise axis label, tooltips and gesture control is another import things need to consider. If the packages provide flexible customisation and charting tool or gesture support, it speeds up the chart implementation time and most important lower difficulties on later packages upgrade risk. Where the risk comes from? Sometimes, we need to override the classes for customisation. If the packages originally not expected developer to override classes, the change of classes may leads to conflict with the extended classes we have. This increases the difficulty.
Maintenance also need to be take into account. By experience, many people including I will have an impression that official plugin or library should have better compatibility with the official framework. I think Flutter Community breaks this 😆. Chart package and WebView package prove this. I somehow understand they want to put more effort on the main features and at the same time community really produced many valued packages. I will explain more on the later part about why I think the chart package from Google is not as good as the others for now, but even official one has not been updated for 9 months. Checking the issue and PR board before selecting a package is vital.
Information last updated: 04/08/22
| Name | Type | Maintenance Status | License | Chart Types | Chart Feature Support | Reference |
| high_chart | WebView with highchart.js | 3 months ago | MIT for package. HighChart.js has its own commercial license required. | Rich variety types, types depends on the products have more chart types | Very flexible customisation | HighChart.js |
| flutter_echarts | WebView with ECharts | 9 months ago, looks have issue with Android 10+ | BSD 2-Clause for package. ECharts is under Apache license. | Rich variety types, including 3D charting | Very flexible customisation | ECharts |
| syncfusion_flutter_charts | Native | few days ago, active | Syncfusion License. If you have ≥5 dev in organisation and gross revenue ≥ 1million USD, you cannot use their community license | 30+ chart types support | Very flexible customisation | Syncfusion |
| mp_chart | Native, translated from MPAndroidChart, a popular Android open source chart library | 11 months ago, flutter 3.0 fix PR pending, looks discontinued | Apache-2.0 | 7+ chart types support | Very flexible customisation | |
| charts_flutter | Native, Google package | 9 months ago, many PR accumulated | Apache-2.0 | 7+ chart types support | Flexible customisation, bad tooltip support or in other word, you need to paint it yourselves | |
| fl_chart | Native | few hours ago, active | MIT | 5+ chart types support | Flexible customisation, very good animation support |
If the application requires complex type charting, I will suggest using syncfusion_flutter_charts. If this package types does not fulfil the requirement, then I will recommend using either highchart or echarts depends on the source volume and license cost. However, if there is not much user interaction, in other words, only display, fl_chart can also be take consideration.
mp_chart is really a great package. Some of my early projects are using this for charting. Due to the maintenance status, I am not going to use it unless I force to be as I don’t want to fork the version myself while there are many other options.
charts_flutter is also a good package on charting. Despite accumulated PRs, I hope they can enhance the tooltip implementation. AFAK, the tooltip can only able to paint with the chart’s provider returned value which takes time for me to calculate a dynamic coordinate tooltip when user is able to adjust visible range. I won’t consider this package if this issue or design is not settled.
If you have any comment or experience about charting on Flutter project, please kindly reply on thread and let everyone not to repeat the same mistake.