SwiftUICharts 2.0.0: AppPear/ChartView's Composable Rewrite

What SwiftUICharts 2.0.0 Solves for iOS Developers

Drawing a chart in SwiftUI without a library usually means either wrapping a UIKit view in UIViewRepresentable or hand-rolling a Path. SwiftUICharts targets the second problem: it gives you LineChart, BarChart and PieChart as SwiftUI views that accept data through modifiers, so chart configuration reads like the rest of your view code. The README describes the package as "a composable, SwiftUI-native chart library for iOS 13+", and the 2.0.0 release is explicitly framed around "immutable configuration, environment-driven composition, and modifier-based APIs".

The audience is narrow and clear. You are building an iOS app in SwiftUI, you already have numeric series in memory, and you want axis labels, grid lines and selection handling without writing a rendering layer. The README's own AI agent section tells code generators to use only 2.x composable APIs and to avoid the 1.x types, which is a signal that the project now expects new code to look a specific way. If you are maintaining a 1.x integration, this release is a migration project, not a drop-in upgrade.

Modifier Composition and the Data Source Contract

The mechanism is SwiftUI ViewModifier stacking. You build a chart by nesting container views and attaching modifiers, and the README's quick start shows the shape: AxisLabels wraps ChartGrid, ChartGrid wraps LineChart, and the data and styling arrive as modifiers on the chart itself. Axis configuration sits on the outer AxisLabels container, which is how the library aligns labels across multiple charts in one stack. That is the point of the AxisLabels and ChartGrid wrappers rather than a single monolithic chart view.

Data semantics are split by type, and the README is explicit about it. Passing chartData([Double]) means categorical slots, while chartData([(Double, Double)]) means a numeric or continuous domain. That distinction decides how the x axis is computed, so picking the wrong one changes the chart rather than raising an error. Ranges are set separately through chartXRange and chartYRange. Interaction has two modes: chartInteractionValue(...) shares a ChartValue across views so a drag on one chart updates a label elsewhere, and chartSelectionHandler { event in ... } delivers a callback with isActive, value and index. Streaming is handled by a ChartStreamingDataSource with initialValues, windowSize and autoScroll, and the README pairs it with stream.suggestedYRange so the y axis follows the window.

Installing SwiftUICharts 2.0.0 with Swift Package Manager

The README gives one installation path: Swift Package Manager. There is no CocoaPods or Carthage instruction in the README, so SPM is the supported route. Add the repository URL as a package dependency and pin the version. The README says to use tag 2.0.0, or from: "2.0.0" up to the next major, which keeps you on 2.x and away from the 1.x API surface.

// In Xcode: File > Add Package Dependencies
// URL: https://github.com/AppPear/ChartView
// Dependency Rule: Up to Next Major from 2.0.0

Once the package resolves, a first chart is the quick start from the README. Import both modules, then compose AxisLabels, ChartGrid and LineChart, and attach the data and range modifiers to the chart.

import SwiftUI
import SwiftUICharts

struct DemoView: View {
    var body: some View {
        AxisLabels {
            ChartGrid {
                LineChart()
                    .chartData([12, 34, 23, 18, 36, 22, 26])
                    .chartYRange(10...40)
            }
            .chartGridLines(horizontal: 5, vertical: 6)
        }
        .chartXAxisLabels(["M", "T", "W", "T", "F", "S", "S"])
        .frame(height: 220)
    }
}

What you should see is a line chart with seven categorical points, a y range clamped to 10 through 40, six horizontal grid lines and the weekday labels along the x axis. The README also points at Examples/SwiftUIChartsShowcase, which it calls the showcase app demonstrating all major features, and that is the fastest way to see mixed bar and line, streaming and performance mode side by side.

Where SwiftUICharts 2.0.0 Breaks and Where It Stops

The largest constraint is the migration itself. The README states plainly that this is a major breaking release and points to MIGRATION.md and example.md. The legacy list is concrete: LineChartView, BarChartView, PieChartView and MultiLineChartView are out, along with the mutating chains .data(...), .rangeX(...), .rangeY(...), .setAxisXLabels(...), .setNumberOfHorizontalLines(...) and the old .showChartMarks(...) form. Any codebase built on 1.x has to be rewritten at every chart call site, and the README does not document a compatibility shim or a rollback path.

The platform floor is iOS 13+. The README names no other platform, so if you ship a macOS or watchOS target you are outside what the documentation covers and should assume the package does not serve you. Performance is the second boundary. The README offers chartPerformance(.automatic(threshold: 600, maxPoints: 180, simplifyLineStyle: true)) for large datasets, and the parameter names describe the trade: above a threshold of 600 points the chart caps rendering at 180 points and simplifies the line style. That is a visual approximation, not a full-fidelity render, and the README does not state how the downsampling is chosen. If your users need to inspect individual values in a series of several thousand points, this is the wrong tool.

SwiftUICharts Compared with Swift Charts

The obvious alternative for a SwiftUI app is Apple's own Swift Charts framework, and the difference is in the API model rather than the chart types. Swift Charts builds a chart from a declarative specification over your data, using mark types and plottable values, and it is maintained by Apple alongside the platform. SwiftUICharts instead layers modifiers on chart view types, with a separate AxisLabels and ChartGrid wrapper deciding alignment and grid rendering. If you want the platform vendor's API and its release cadence, Swift Charts is the safer default.

SwiftUICharts earns its place in two situations the README makes visible. First, iOS 13 support: Swift Charts arrived in a later iOS release, so a project that still targets iOS 13 cannot use it. Second, the built-in interaction and streaming pieces. The README ships a ChartStreamingDataSource with windowSize and autoScroll and a shared ChartValue that several charts can bind to, so a dashboard of linked charts is a small amount of code. In Swift Charts you would assemble that state handling yourself. The trade is that you inherit a library with a breaking 2.0 migration and a smaller documented surface than a first-party framework.

Maintenance, Licence and the Cost of Staying on 2.x

The repository is not archived, and the last push was on 2026-03-02, the same day release 2.0.0 was tagged. That is roughly six months before today, so the project shows a recent major release rather than a long-running stream of updates. The gap before it is worth noting: the previous tags were 2.0.0-beta.8 in 2022 and 2.0.0-beta.7 in 2022, so the 2.x line sat in beta for several years before the stable tag. Plan for a slow release cadence and pin your dependency rather than tracking the branch.

The licence is MIT, which permits commercial and closed-source use with the copyright notice and permission notice retained. That is a permissive licence and it is the same family used by most Swift packages. This is a description of the licence text, not legal advice; if your organisation has a licence review process, route it through that. On upgrade cost, the README points to CHANGELOG.md and MIGRATION.md, and the package ships an Apple privacy manifest at Sources/SwiftUICharts/PrivacyInfo.xcprivacy, which matters if your App Store submission requires a privacy manifest. The README does not document a deprecation window for the 1.x API, so treat the 1.x surface as gone rather than supported.

Editorial conclusion

Adopt SwiftUICharts 2.0.0 if your app is already SwiftUI and you want line, bar and pie charts composed from modifiers rather than wrapped UIKit views. Stay on 1.x or pick another library if you ship on iOS 12, need macOS or watchOS, or cannot absorb a breaking migration across an existing chart layer. Before you commit, open MIGRATION.md and confirm every 1.x call site in your codebase has a 2.x replacement, then set the package dependency to from: "2.0.0" and build the showcase at Examples/SwiftUIChartsShowcase to see the modifier set in motion.

Frequently asked questions

Official sources

1. AppPear/ChartView on GitHub
2. Issues
3. License: MIT
4. README
5. Releases