ActivityIndicatorView gives SwiftUI ten spinner styles behind one enum

One view, one enum, ten presets

The whole API is a single view initialiser taking a type from ActivityIndicatorView.IndicatorType:

ActivityIndicatorView(type: .default)

Because it is an ordinary SwiftUI view, you modify it with standard SwiftUI modifiers rather than through a configuration object:

ActivityIndicatorView(type: .growingArc(.red, lineWidth: 4))
    .frame(width: 50.0, height: 50.0)
    .foregroundColor(.red)

That is the design decision that makes this package worth taking. Colour usually goes through foregroundColor on the whole view, while a type like growingArc also takes a colour directly as its first parameter, and gradient takes an explicit array of colours. You can therefore combine both mechanisms or pick per style.

The README's advice on parameters is worth heeding: each type has defaults that are meant to look reasonable, and setting them too high or too low is what makes these indicators look wrong.

What the ten types actually are

The list is short enough to read in full, and the parameters differ more than you would expect. default is the iOS UIActivityIndicator style and takes .default(count: 8). arcs takes count and lineWidth, for example .arcs(count: 3, lineWidth: 2). rotatingDots takes a count, as does flickeringDots.

The dots family splits three ways by animation. scalingDots takes count and inset, opacityDots takes count and inset, and equalizer takes only a count. The inset is what separates the two, and it is the parameter you adjust when dots look crowded inside a small frame.

growingArc takes a colour, defaulting to Color.black, and a lineWidth. growingCircle takes no parameters at all, so it is the one style where you have nothing to tune. gradient is a circle with an angular gradient border stroke and takes an array of colours plus a lineWidth, for example .gradient([.white, .red], lineWidth: 4).

Any SwiftUI view is still a view, so scale, opacity, rotation and animation modifiers all work on top of whichever type you pick.

Installation: Swift Package Manager, and CocoaPods is on the way out

The supported route is Swift Package Manager, and the dependency declaration is the whole of it:

dependencies: [
    .package(url: "https://github.com/exyte/ActivityIndicatorView.git")
]

The CocoaPods badge says Deprecated after 1.1.1.

The platform requirements are iOS 13 or later, watchOS 6, tvOS 13 and macOS 10.15, with Xcode 11. That spread is broader than most SwiftUI packages claim, and it is the reason this one is worth knowing about: the same view works across all four Apple platforms, so a project with a multiplatform target set does not need a fallback implementation for the smaller ones.

The repository root has Package.swift and a Sources/ directory, plus ActivityIndicatorViewExample/ for the sample app. The example is the fastest way to see all ten animating.

Running the examples and what a demo project tells you

The README gives one instruction for trying the indicators: clone https://github.com/exyte/ActivityIndicatorView.git, open ActivityIndicatorViewExample.xcodeproj, and run it. There is no command line step and no build tool beyond Xcode.

That is a small thing, but it is the right shape for this package. The open question in any indicator library is how a style looks at the size you will actually use it, and the answer is not derivable from a parameter list. A .growingArc with lineWidth 4 that reads well in a 200 point placeholder can disappear in a 24 point table cell footer, and no API will tell you that.

So the practical workflow is: add the package, drop the example project's view list into a scratch screen in your own app at your own sizes, and tune from there. Copying a count and inset out of the README without checking it at size is the most likely way to end up with a spinner that looks broken.

The .swiftpm/ directory in the repository root is package manager configuration rather than anything you need to touch.

Maintenance state, licensing and the limits of the abstraction

The repository is not archived and the last push was on 2026-09-10, so it is not a project that has been left to rot. That said, there are no GitHub releases. The version badge points at repository tags, so if the tags exist they carry the number rather than a curated release.

The license is MIT. Nothing in the README suggests a licensing question for an app that ships the indicator.

The functional limitation is the honest one: every type exposes only the parameters listed, and several take just a count. There is no control over animation duration, no easing curve, no pause on appearance of a background view, and no documented behaviour under the reduced motion accessibility setting. If your app needs an indicator that matches a brand's motion spec, or that respects an accessibility preference, you will be writing a SwiftUI view by hand rather than configuring one of these.

For the plain case, which is most cases, this is a good answer: ten styles, one file each, no dependencies.

Editorial conclusion

Adopt ActivityIndicatorView if your SwiftUI app needs a loading indicator that does not look like the system spinner and you install through Swift Package Manager, since CocoaPods support is marked deprecated after 1.1.1. Do not adopt it to customise timing, colours per state or reduced motion, because every type takes only the parameters listed in the README. Before adding it, check that the Swift Package Manager dependency string is all you need for your platform, confirm iOS 13, watchOS 6, tvOS 13 and macOS 10.15 are acceptable floors, and note that the repository has no GitHub releases.

Frequently asked questions

Official sources

1. exyte/ActivityIndicatorView on GitHub
2. Issues
3. License: MIT
4. README