AAChartKit: a Highcharts-backed declarative chart framework for iOS, iPadOS and macOS

The problem AAChartKit solves for Apple platform teams

Drawing a chart with Core Graphics or a native view layer means writing axis math, tick placement, label collision handling and animation frames yourself. AAChartKit takes that work away by putting the Highcharts JavaScript library behind an Objective-C interface. The README describes the project as "an elegant and friendly chart framework for iOS, based on the open source Highcharts JS libraries", and lists column, bar, area, areaspline, line, spline, radar, polar, pie, bubble, pyramid, funnel, columnrange, arearange and mixed charts among the supported types. The stated target is iOS, iPadOS and macOS, in Objective-C, with sibling projects for Swift, Java and Kotlin.

The audience is narrow and specific. This is for an Apple platform codebase that is written in Objective-C or that already bridges to it, where the team wants a large catalogue of chart types without maintaining a rendering engine. If your project is pure Swift and has no Objective-C in it, the README points to the Swift version instead, and that is the more direct route.

How the AAChartView and AAChartModel pair renders a chart

The architecture follows a formula the README states outright: "AAChartView + AAChartModel = Chart". AAChartView is the view you place in your hierarchy. AAChartModel is a value object that describes the chart you want: type, title, series data, stacking, animation, legend and axis configuration. You configure the model, hand it to the view, and the view produces the chart.

That description implies a rendering path through a web view. The repository topics include webview and highcharts, and the README says the framework is based on the Highcharts JS libraries, so the chart is drawn by JavaScript inside a web view that the Objective-C layer configures. The declarative claim in the README is the point of this design: "Describe what you want, you will get what you described." The README also states that the API supports chain programming syntax, in the style of Masonry, so model properties can be set in a fluent sequence rather than one assignment per line.

Two consequences follow from that structure. First, everything Highcharts can do is reachable in principle, because the configuration is passed down to it. Second, the chart is not a native view, so it carries the cost of a web view and a JavaScript runtime inside your app. The README also documents interaction event callbacks for user click events and single finger move over events, which the project says can drive linked charts and other custom interaction effects.

Installing AAChartKit with CocoaPods and drawing a first chart

The repository contains an AAChartKit.podspec at its top level, and the homepage listed for the project is its CocoaPods page, so CocoaPods is the documented distribution channel. The pod is named AAChartKit. Add it to your Podfile and run the install command.

pod 'AAChartKit'
pod install

After installation, the working pattern is to build a model, configure it, and attach it to a chart view. The README's own formula is the shape to follow: create the AAChartView, create the AAChartModel, then connect them. The exact property names for each chart type are not enumerated in the README text; the repository ships an AAChartKitDemo Xcode project alongside the library, and that demo is where the concrete configuration examples live. Expect to read the demo target rather than the README when you need a specific property name.

The README does not print a complete Objective-C snippet for building a model and drawing it, so there is no code block to copy here. The README's own formula, AAChartView plus AAChartModel, is the sequence to reproduce, and the AAChartKitDemo target is the reference for the method names and property names the current version expects.

Where AAChartKit is the wrong choice

The web-view renderer is the main constraint, and it is not a small one. A chart that is drawn by JavaScript inside a web view has to load that JavaScript, and the view has to be laid out and sized before the chart can be drawn correctly. In a table or collection view where cells are recycled quickly, that lifecycle is harder to manage than a native view that draws synchronously. The README does not discuss reuse behaviour in scrolling containers, so that is a question you will have to answer yourself against the demo.

There is also a dependency question the README leaves open. The project is based on Highcharts, and Highcharts is not the same licence as AAChartKit. The repository's LICENSE file is MIT, and the podspec is the place to check what the pod actually declares. A team that assumes the MIT licence on the wrapper covers the JavaScript it loads is making an assumption the README does not support.

Finally, this is a large framework for a small need. If you want one line chart with a fixed dataset, the model-plus-view indirection, the JavaScript bridge and the extra binary size are all overhead you would not pay with a native drawing approach. The README's own framing, dozens of chart types and a declarative model, only pays off when you actually need that breadth.

AAChartKit compared with DGCharts and the Swift AAInfographics sibling

DGCharts is the other name that comes up when people search for this project, and the difference is architectural rather than cosmetic. DGCharts draws on the native Apple graphics stack, so a chart is a real view with no web view and no JavaScript involved. That makes it a better fit when rendering must be predictable in recycled cells, when you want no scripting runtime in the binary, or when the app must behave identically without a web engine. The trade is that you get the chart types DGCharts implements, configured through its own API, rather than the full Highcharts configuration surface.

The second alternative is the project's own Swift sibling, AAChartKit-Swift, which the README links under the name AAInfographics. It is the same approach and the same Highcharts foundation, in Swift instead of Objective-C. If your codebase is Swift, choosing the Objective-C framework means adding an interop boundary for no benefit, and the README explicitly points Swift users at the sibling project. The Java version, AAChartCore, and the Kotlin version exist for the same reason on other platforms. Picking AAChartKit itself only makes sense when Objective-C is already the language of the surrounding code.

Maintenance, release cadence and the cost of upgrading

The repository is not archived, and the last push was on 2026-05-12. The release history shows 10.0.0 on 2026-04-21, 9.0.0 on 2024-06-05, and 5.0.2 on 2020-07-03. Read those dates together and the cadence is uneven: a long gap between 5.0.2 and 9.0.0, another gap of roughly two years before 10.0.0, then a push a few weeks after the latest release. That pattern argues against treating upgrades as routine. The jump from 9.0.0 to 10.0.0 is a major version, and the README does not document a migration path or a deprecation list for it, so budget time to read the diff rather than assuming the model properties you use are unchanged.

On licensing, the repository carries an MIT LICENSE file, which is permissive and generally low-friction for commercial apps. The complication is the Highcharts dependency underneath, which is a separate work with its own terms. Nothing in the README states how that dependency is licensed for your use case, and this is not a question to settle by reading the wrapper's licence file alone. Check the podspec and the Highcharts licensing terms against how you intend to ship before you build on it.

Editorial conclusion

Adopt AAChartKit when your app is already Objective-C or Objective-C interop and you need many chart types quickly, and when a web-view renderer is acceptable. Do not adopt it when you need offline-first rendering with no JavaScript engine, or when your charting needs are one simple line chart that a native view could draw. Before you commit, open the AAChartKit.podspec to confirm the version and the deployment targets it declares, and check whether the AAChartModel properties you need are documented in the README or only in the demo project.

Frequently asked questions

Official sources

1. AAChartModel/AAChartKit on GitHub
2. License: MIT
3. Project website
4. README
5. Releases