ChartsOrg/Charts (now DGCharts) for iOS, tvOS and macOS: a practical adoption review

What ChartsOrg/Charts solves, and who it is actually for

The README opens with the origin story: MPAndroidChart by Philipp Jahoda was popular on Android, and "there was no decent solution to create charts for iOS." Charts is the Swift rewrite of that library for Apple platforms. It targets iOS 12.0 and later, tvOS 12.0 and later, and macOS 10.13 and later, and it is written in Swift so it can be consumed from Swift and Objective-C projects. The demo project is Objective-C, which the README presents as proof that the Objective-C path works.

The intended audience is an app team that needs charts inside a UIKit view hierarchy and does not want to build axis layout, touch handling and animation from scratch. The README also makes an argument for cross-platform teams: the learning curve is described as a "singleton" because the code stays similar between the Android and Apple sides, so a developer who knows MPAndroidChart can move to Charts without relearning the model.

That framing tells you who it is not for. If your interface is SwiftUI-first, the library is a UIKit framework you embed, and the README points to third-party blog posts about SwiftUI integration rather than shipping an official SwiftUI wrapper. If you need two or three chart types and nothing more, the surface area here is larger than the problem.

How the framework is put together and what the data flow looks like

The repository layout is a conventional Xcode framework project: a Source directory, a Charts.xcodeproj and a Charts.xcworkspace, a DGCharts.podspec, a Package.swift, plus separate demo projects for iOS and macOS. There is no server component and no runtime data source. You hand the chart view a data object, and the view draws it.

The README does not document the internal renderer pipeline in any detail, so the mechanism you can confirm is the integration contract: drag the project in or add the package, embed the framework, then import it. The README's usage steps name the framework DGCharts.framework and the import statement @import DGCharts, which is the renamed identity introduced in 5.0.0.

One binding is worth calling out because it changes your dependency graph. Realm support is optional and separate. The README states the Realm framework is not linked with Charts, that the bindings exist only as an optional extra, and that you must add ChartsRealm as an additional dependency if you want them. It also warns that the Realm framework must be in a version compatible with whatever DGCharts was compiled against. That is a real coupling you inherit, not a detail.

Installing DGCharts and drawing a first chart

Three package managers are documented. CocoaPods is the shortest path: add the pod named DGCharts to your Podfile, and add ChartsRealm as well only if you want the Realm bindings.

pod 'DGCharts'

Swift Package Manager uses the repository URL and an upToNextMajor constraint from 5.1.0, which is the release the README's snippet pins.

dependencies: [
    .package(url: "https://github.com/ChartsOrg/Charts.git", .upToNextMajor(from: "5.1.0"))
]

Carthage consumers get prebuilt binaries. The README shows two forms, an exact pin and a compatible-range pin, both on 5.1.0.

github "ChartsOrg/Charts" == 5.1.0
github "ChartsOrg/Charts" ~> 5.1.0

If you would rather not use a package manager, the README's manual route is to drag DGCharts.xcodeproj into your project, open your target's settings, use the plus button under Frameworks, Libraries, and Embedded Content, and select DGCharts.framework. Then import it with @import DGCharts.

Two constraints apply before any of this works. The README says master expects Xcode 14 and Swift 5.7, and it advises against checking out master if you are not on the latest Swift compiler; instead, pick a release tag that suits your toolchain. For an Objective-C host project, the README adds that you import your generated bridging header, typically YourProject-Swift.h, and that on Xcode 8.2 and later you mark Always Embed Swift Standard Libraries under Build Options. It explicitly warns not to try to include that generated header in your project.

The repository ships two demo apps, ChartsDemo/ChartsDemo.xcodeproj for iOS and tvOS and ChartsDemo-OSX/ChartsDemo-OSX.xcodeproj for macOS. The README suggests running carthage checkout in the project folder to fetch test dependencies if you want the demo to build.

The 5.0 rename is the real adoption cost

Charts 5.0 renamed the library to DGCharts to avoid a collision with Apple's own Swift Charts. The README flags this as a breaking change and links to the 5.0.0 release notes for migration guidance. Practically, that means every import line, every Podfile entry and every framework reference in an existing project changes name. New projects pay nothing. Projects already on 4.x pay a mechanical but wide edit.

The README itself is inconsistent about this, and that inconsistency is a signal. The top of the file still says "Version 4.0.0" and syncs to MPAndroidChart commit f6a398b, while the usage section and package instructions all use DGCharts and 5.1.0. A reader skimming the header could conclude they are installing a 4.x library. Treat the release notes, not the README header, as the version of record.

There is a second trap the README names directly. The pod name ios-charts is struck through and described as not the correct library, referring to a different project by someone else. If you copy a pod line from an old tutorial, you get the wrong dependency.

Where DGCharts is the wrong choice

The clearest boundary is SwiftUI. Apple's Swift Charts is the reason this library was renamed, and it is the native answer for a SwiftUI-first app. If your screens are declared in SwiftUI, embedding a UIKit framework and bridging it is work you do not have to do. The README does not ship an official SwiftUI integration; it links to third-party posts instead.

Toolchain drift is the second boundary. The README's own advice is that if you are not on the latest Swift compiler you should not check out master, and that you should pick a release tag that suits you. That is an admission that master is not a safe tracking branch for slower-moving teams. A project pinned to an older Xcode cannot simply follow the default branch.

The third boundary is the optional Realm binding. The README warns that the Realm framework is not linked with Charts and must be in a version compatible with what DGCharts was compiled against. If your persistence layer is Core Data, SwiftData or a plain SQLite wrapper, this whole branch of the documentation is irrelevant to you, which is fine, but it also means the Realm path is a maintenance surface you inherit only if you opt in.

Finally, the troubleshooting section is thin. It tells you to reread the Usage section, search the issues, and ask politely in the issues. There is no documented rollback procedure and no compatibility matrix beyond the platform minimums. If your team needs a vendor with a support contract, this is a community project.

DGCharts against Apple's Swift Charts

The difference is not feature count, it is integration model. DGCharts is a UIKit framework you embed, with an Objective-C-compatible API and a demo project written in Objective-C to prove it. Swift Charts is Apple's own framework, and the rename in 5.0.0 exists precisely because the two names collided. Choosing between them is choosing between a UIKit view you configure imperatively and a SwiftUI-native declarative API.

The second difference is reach. DGCharts covers iOS, tvOS and macOS from one codebase with a stated platform floor of iOS 12, tvOS 12 and macOS 10.13. That floor matters if you still support older deployment targets. It also shares its model with MPAndroidChart, so a team maintaining both an Android and an Apple app can keep the chart code conceptually aligned, which is the argument the README makes at length.

The third difference is control. A framework that draws its own axes, markers and animations gives you hooks that a higher-level API may not expose. The README's third-party tutorial list is dominated by posts about custom markers and per-chart-type setup, which suggests that is where users spend their time.

Maintenance, licensing and what to check before you pin

The repository is not archived, and the last push was on 2026-03-07. The most recent release listed is 5.1.0 from 2024-02-16, preceded by 5.0.0 in 2023 and v4.1.0 in 2022. So the default branch has moved more recently than the last tagged release, which is consistent with the README's advice to pick a tag rather than track master. There is a CHANGELOG.md, a CONTRIBUTING.md and a SECURITY.md at the top level, so the project does document its change history and its contribution and disclosure paths.

The licence is Apache-2.0. That is a permissive licence, and it is the same family used by many mobile libraries. It is not legal advice, and you should have your own counsel review it if you redistribute the framework or modify it, particularly around the notice and attribution requirements Apache-2.0 carries.

Upgrade cost has three components here. The 5.0 rename touches every import and dependency declaration. The Swift compiler constraint means an upgrade may be gated by your Xcode version rather than by the library. And the optional Realm binding adds a second version-compatibility axis if you use it. Pinning to a tag and reading the release notes for that tag is cheaper than tracking master and discovering a break at build time.

Editorial conclusion

Adopt DGCharts if you are shipping a UIKit app on iOS 12 or later and need many chart types behind one API, and accept the 5.0 rename and the Swift 5.7 master branch. Do not adopt it if you are building SwiftUI-first and want to stay on Apple's own Swift Charts, or if you need a chart type the library does not implement. Before writing code, confirm the tag you will pin, check that your toolchain matches the compiler the tag expects, and read the 5.0.0 release notes for the DGCharts rename.

Frequently asked questions

Official sources

1. ChartsOrg/Charts on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases