GradientProgressBar paints a UIProgressView with a gradient, in SwiftUI and UIKit

A UIProgressView with a gradient drawn into it

GradientProgressBar is a customizable gradient progress bar built on UIProgressView, with support for both SwiftUI and UIKit, and it is inspired by an iOS 7 progress bar posted on CodePen. The design is deliberately period-appropriate rather than following whatever the current platform look happens to be.

The implementation is a UIProgressView subclass, so the useful consequence is that everything you already know about a progress view still holds. Updating progress is the same as with the system view, and the README shows both the animated form and the direct property assignment:

gradientProgressBar.setProgress(0.75, animated: true)

and

gradientProgressBar.progress = 0.75

Subclassing rather than replacing means the view keeps the standard layout behaviour, the accessibility characteristics of the platform control, and the tint handling, and what you add is the gradient fill and a rounded background. The library is distributed through Swift Package Manager as of the current version, and the example project in the Example directory is where the result is shown.

The version lines encode the deployment target

The requirements section is where a reader has to slow down, because the current line is narrow. The listed requirements are Swift 6.2, Xcode 26 and iOS 26.0 or newer.

The compatibility notes then map older targets onto older lines. For iOS below 26.0, and for CocoaPods or Carthage support, use the 3.x line. For iOS below 13.0, use the 2.x line.

That is a significant shift for a small view library, and it is worth being explicit about the consequences. A project that has not yet moved to iOS 26 cannot take 4.x, and if it is still on CocoaPods or Carthage it cannot take 4.x either, so it stays on 3.x. A project that must support iOS 12 or older is on 2.x, which is a line that predates the SwiftUI integration.

The practical approach is to pick your line from the deployment target and the package manager rather than from the version number, and to treat the two older lines as frozen. The repository publishes a single release tag for the current line, 4.0.0, and the older lines are reachable through the version rules in the package manager.

SwiftUI gets a ProgressViewStyle

Since version 2.1.0 the library provides a custom ProgressViewStyle for SwiftUI, and that is the integration to reach for in a SwiftUI codebase. The style is applied to a standard ProgressView with the value variant:

ProgressView(value: progress)
  .progressViewStyle(.gradientProgressBar)
  .frame(height: 3)

The style is configured with three parameters, a background color shown behind the gradient and clipped by the corner radius, the array of colors used for the gradient, and the corner radius applied to both the background and the bar.

ProgressView(value: progress)
  .progressViewStyle(
    .gradientProgressBar(
      backgroundColor: .gray.opacity(0.05),
      gradientColors: [.indigo, .purple, .pink],
      cornerRadius: 1.5
    )
  )

The animation model is the one difference from UIKit, and it is a good one. Where the UIKit view animates itself through an animationDuration property, the SwiftUI style animates through the standard view modifier, with the animation applied to a value:

ProgressView(value: progress)
  .progressViewStyle(.gradientProgressBar)
  .animation(.easeInOut, value: progress)

That means the style plays by SwiftUI's rules rather than imposing its own timing, and the README points at Apple's Animation documentation for anything more elaborate.

The UIKit view is a plain view with three knobs

On the UIKit side the view is added to a view hierarchy the ordinary way, with Auto Layout constraints rather than a frame, and the height is set by a constraint of 3 points in the example, which is the thin bar look the library is often used for.

The configuration is three properties. The animationDuration is a TimeInterval controlling the duration of animated updates when setProgress is called with the animated flag. The gradientColors array holds the colors used for the gradient. The timingFunction adjusts the animation timing for those animated updates, and the pre-defined timing functions live in a file named TimingFunction.swift in the Model directory of the sources.

let gradientProgressBar = GradientProgressBar()
gradientProgressBar.animationDuration = 1
gradientProgressBar.gradientColors = [.systemIndigo, .systemPurple, .systemPink]
gradientProgressBar.timingFunction = .easeInOut

The naming is worth noting if you move between the two integrations. The SwiftUI style takes a background color, a colors array and a corner radius, and it has no animation duration of its own. The UIKit view takes the colors, a duration and a timing function, and the corner radius comes from the view itself rather than from a style parameter.

A WKWebView progress bar through key-value observing

The example app shows a use case that has nothing to do with network requests of your own: attaching the bar to a navigation bar to show how far a web view has loaded.

The mechanism is Key-Value Observing on the estimatedProgress property of WKWebView. The progress bar updates as the page loads, with no polling and no delegate callbacks, and the README says the example project has a complete implementation, based on a gist by the author.

This is the kind of integration that is awkward to build by hand, because estimatedProgress is a continuously updated estimate rather than a completion callback, and observing it gives you a value to drive an animated bar with. Because the library is a UIProgressView subclass, the view can also be used as the navigation bar's progress indicator in the way UIKit provides for that, which is what the example does.

The caveat is the same as any observation-based approach: the observation has to be removed when the object goes away, and the example is the place to see how that is handled.

Where the library is the wrong choice

The first limit is the deployment target, already covered. A library whose current line needs iOS 26 rules out a large part of the installed base, and while the older lines exist, they are the older code.

The second limit is the size of the effect. This is a gradient on a progress bar, and if what you need is a progress bar that matches a brand, the cost of a few lines of Core Animation or a custom layer may be lower than taking a dependency, especially in a project that has to support systems where the current line does not run.

The third is the asymmetry between the two integrations. The SwiftUI style and the UIKit view are not the same feature in two clothes. The style has no duration knob and relies on SwiftUI's animation modifier, while the UIKit view has its own duration and timing function. Code that moves between the two is not a straight port, and the SwiftUI style is also the newer of the two, added in 2.1.0, so it has had less time to accumulate edge case fixes.

The fourth is the scope. There is no determinate or indeterminate variant beyond the base UIProgressView behaviour, no styling of the track beyond a color and a radius, and no support for a custom gradient type beyond an array of colors, so if your design needs a gradient along an angle or a masked image, this is not the library.

Package layout, licence and maintenance

The current release is 4.0.0, published on 2026-01-31, and the last push to the repository was on 2026-10-08, with the repository not archived. The README badges show the Swift version, the continuous integration status, code coverage, the release version and the platform, and the platform badge reads iOS.

The package is distributed via Swift Package Manager, and both installation routes are documented. In Xcode you add the package through the File menu, entering the repository URL and choosing a version rule, and in a Package.swift file you add it to the dependencies section:

dependencies: [
  .package(
    url: "https://github.com/fxm90/GradientProgressBar",
    from: "4.0.0"
  )
]

The product is then referenced in the target configuration, and the module is imported where it is used:

import GradientProgressBar

The licence is MIT, with the LICENSE file in the repository, and the author is Felix Mau. The repository also carries a CocoaPods badge, which is a trace of the older distribution route that the 3.x line still serves, and the topics list covers Swift, iOS, UIProgressView, gradient and CocoaPods.

Editorial conclusion

GradientProgressBar fits an iOS team that wants a gradient progress bar without hand-rolling a layer, and that is comfortable with the current line's iOS 26 requirement since the SwiftUI style and the UIKit view are both maintained together. It is the wrong choice for an app that still supports older systems unless you are prepared to pin the 3.x or 2.x line instead. Before you adopt it, check three things: which line you are on, since 4.x needs iOS 26 with Swift 6.2 and Xcode 26 while 3.x is the pre-26 line, whether you need the SwiftUI style or the UIKit view, since the SwiftUI integration arrived in 2.1.0 and the animation model differs between the two, and that your build is on Swift Package Manager, which is how 4.0.0 is distributed. The licence is MIT, the current release is 4.0.0 from 2026-01-31, and the last push was on 2026-10-08.

Frequently asked questions

Official sources

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