KLineChart in Production: What We Added

What KLineChart Is

KLineChart is an open-source financial charting library, canvas-based, framework-agnostic, and licensed under Apache 2.0. It handles the part that is genuinely hard to write well: drawing candles at sixty frames per second, panning and zooming a large series without stutter, stacking indicator panes, and hit-testing drawing tools against pixel coordinates.

The licensing matters as much as the rendering. TradingView's Advanced Charts requires an application and approval before you can ship with it, and the Lightweight Charts license carries attribution requirements of its own. Apache 2.0 asks you to preserve the notice and gives you the rest. For a team that wants to ship without waiting on a licensing decision, that difference is the whole decision.

We credit it on the chart itself, alongside the upstream NOTICE file, because that is what the license asks for and because it is true.

• Canvas rendering, framework-agnostic, actively developed.
• Apache 2.0: no approval gate, no application to file.
• Currently shipped here as v10.0.0-beta1.

What a Charting Library Does Not Do

A charting library takes an array of candles and draws them. Everything required to get that array, and everything you want to do once it is on screen, is outside its scope by design. That is not a criticism. A library that tried to own all of it would be unusable for most of the people who pick it.

The list of what is missing is longer than it first appears. There is no market data layer, so no broker connections, no authentication, no rate-limit handling and no reconnection logic. There is no symbol resolution, so nothing decides that a bare futures root belongs to a particular exchange. There is no persistence, so drawings vanish on reload unless you store them. There is no export. There is no settings surface for indicator parameters. There is no multi-window or multi-workspace concept.

If the chart is your product, you will build most of that anyway and the library saves you the hardest rendering work. If the chart is a means to an end, you will be building a charting application whether you meant to or not.

• No data layer, no broker auth, no rate limiting.
• No symbol or exchange resolution.
• No persistence, no export, no settings UI.

What We Built On Top

The provider layer came first: adapters for each broker and data feed, running against the user's own credentials on the user's own machine, with connection state surfaced honestly rather than assumed. See IBKR vs Alpaca vs Tradier: Costs, Limits, Data Gaps for how much those APIs differ underneath a single interface.

Symbol resolution turned out to be a larger job than expected. Deciding that a bare futures root means the exchange-traded contract rather than an equity that shares the letters is a judgement call with a wrong answer in both directions, and it is written up in IBKR Futures Symbols: ES, NQ, CL and GC.

Then persistence for drawings and notes, structured export of drawings, notes, OHLCV and indicator values, a screener, alerts, and a local connection that lets an AI assistant read the chart as structured context rather than as an image, covered in What an AI Agent Sees on Your Trading Chart.

None of that is work KLineChart should have done. It is the distance between a rendering library and something a trader can open and use.

• Broker and feed adapters running on the user's own credentials.
• Symbol and exchange resolution, including futures roots.
• Persistence, structured export, screener, alerts, AI-readable context.

Which One You Should Actually Pick

If you are building a charting product, use KLineChart directly. It is well-engineered, the license is permissive, and you will want control over the layers above it anyway. Nothing about MyLinedChart existing is an argument against that, and a developer evaluating the library is not a lost customer.

If the chart is not the product, and what you actually need is to look at your own broker data, mark it up, keep the marks, export them and hand them to an AI assistant, then the build is the expensive path. The rendering is the part that was already solved.

The dividing question is not which is better. It is whether charting is the thing you intend to maintain for the next several years.

• Building a charting product: use the library.
• Charting as a means to an end: the build cost is the layers above it.
• Maintenance ownership is the real decision, not features.

Is MyLinedChart built on KLineChart?

Yes. The chart renders with KLineChart, currently v10.0.0-beta1, under the Apache License 2.0, and it is credited on the chart alongside the upstream NOTICE file.

How does the KLineChart license compare to TradingView's charting libraries?

KLineChart is Apache 2.0, which asks you to preserve the notice and grants the rest. TradingView's Advanced Charts requires an application and approval before you can ship with it, so the practical difference is whether shipping depends on someone else's decision.

What do I still have to build if I use KLineChart directly?

The data layer and broker authentication, symbol and exchange resolution, persistence for drawings, export, indicator settings surfaces, and anything multi-window. The library renders; the rest is application work.

Should a developer evaluating KLineChart use MyLinedChart instead?

Not if charting is the product you intend to build and maintain. Use the library directly. The trade only favours a finished application when the chart is a means to an end rather than the thing you are shipping.