Open SwiftUI Animations: A Reference Collection, Not a Library

What Open SwiftUI Animations actually is

The README frames the project as a counter-argument to animation libraries: "Why use an animation library instead of creating these tiny effects yourself?" That is the whole thesis. The repository is a catalogue of small SwiftUI effects, each shown as a GIF preview and linked to a Swift file you can read and copy. Categories visible in the README and the directory names include loading and progress, looping, on-off, enter and exit, fade, spin, background animation, plus what the description calls spring animations. The repository layout confirms the shape: an OpenSwiftUIAnimations.xcodeproj, an OpenSwiftUIAnimations source directory, a Gists_To_Try directory of standalone files, and GIF_Previews for the previews. There is no Package.swift at the top level, so nothing in the repository indicates that this ships as a Swift Package. The audience is an engineer building an Apple-platform app who wants to see how a specific effect is constructed in SwiftUI rather than install something that produces it. If you are looking for a library to add to a dependency list, this is the wrong artefact, and the README says so indirectly by pointing you at its own Xcode project instead of an installation section.

The mechanism: one file per effect, built on Apple's animation APIs

Each entry is a self-contained SwiftUI view. The README states that most animations are based on the animations section of the Apple Developer Documentation, and that the Xcode project contains examples of PhaseAnimator, Symbol Effects, KeyframeAnimator and Spring animations for iOS 17 and beyond. The Liquid Glass example in the README shows the pattern: a GlassEffectContainer wraps a PhaseAnimator that drives a boolean, which switches the HStack spacing between 50.0 and -15.0. That is the data flow for the whole repository: a state value changes, the animation modifier or animator interpolates it, and the view body reads the interpolated value to position, scale, rotate, fade or morph something. Because the effect lives in the view, there is no runtime layer, no registration step and no configuration object. You get the code and you own it. The trade-off is that there is also no shared abstraction: two effects that both need a pulsing scale will each carry their own copy of the logic, and any fix you make stays in your app rather than flowing back to a dependency.

Getting the examples into a project

There is no install command. The README points at the Xcode project for the full set and at individual gists for single effects, so the practical route is to clone the repository and open the project, or to open the gist for the one effect you want and paste it into your own target. Cloning is the only step the repository supports:

git clone https://github.com/amosgyamfi/open-swiftui-animations.git

After that, open OpenSwiftUIAnimations.xcodeproj in Xcode and browse the OpenSwiftUIAnimations group, which is organised by animation category (FitnessActivityAnimations, SlideToCancelAnimations and HumanInitiatedAnimations are three named in the README). Standalone files live under Gists_To_Try. A first real use is to copy one effect into your own view and change the timing curve. The README's own Liquid Glass example starts like this:

PhaseAnimator([false, true]) { morph in
    HStack(spacing: morph ? 50.0 : -15.0) {
        // content
    }
}

What you should see is the content moving between the two states. Because these are plain SwiftUI views, the only integration work is resolving the types and modifiers they reference in your target's deployment version.

Where the repository is thin

The README is a gallery, not documentation. It gives a GIF and a link per effect, and in several places the image has no accompanying file link at all, so you can see the animation but not the source from the README alone; you have to search the Xcode project or the gists directory. There is no stated minimum deployment target per effect, no table mapping effect to API, and no note on which entries need iOS 17 or later even though the README says the PhaseAnimator, KeyframeAnimator and Spring examples target iOS 17 and beyond. That matters in practice: dropping a phase animator into a project that still supports an older iOS version will not compile, and the README does not warn you per file. The repository also has no published releases, so there is no upgrade path to follow because there is nothing packaged to upgrade. Treat every file as a starting point that you review before it enters your codebase, not as reviewed production code.

Maintenance, licence and what copying costs you

The repository is not archived, and the last push was on 2026-08-14. The README also states that from 2025 some animations are generated using models such as Gemini 2.5 Pro, Claude 3.7 Sonnet and OpenAI o3, and the Gemini 2.5 Pro + OpenAI o3 gist carries a note that its animations are unedited and should be modified to suit your needs. That is a direct signal about review depth: generated code sits next to hand-written examples, and only that gist is labelled as generated in the README. The licence is Unlicense, which is a public-domain dedication rather than a permissive licence with attribution conditions, so copying a file into a commercial app does not create an attribution obligation under that licence. Two caveats belong here rather than in legal advice. First, some entries link to GitHub gists outside the repository, and the repository does not state what licence those gists carry, so check the file you actually copy. Second, the examples reference Apple APIs and SF Symbols such as scribble.variable; those remain subject to Apple's own terms regardless of the repository licence. Upgrade cost is close to zero and also close to meaningless: with no package and no releases, there is no dependency to bump, only files you have already forked into your own source tree.

Choosing this over an animation package

The obvious comparison is a SwiftUI animation library you add as a package and call into, where the library owns the interpolation and you pass parameters. The difference is where the effect lives. Here the effect lives in your file, which means you can read every line that runs, change the curve, and delete what you do not need, but it also means you maintain it and you get no upstream fixes. Lottie is the other realistic alternative, and it solves a different problem: it plays designer-authored vector animations from a JSON file exported from After Effects, so the motion is authored in a design tool and shipped as data. Open SwiftUI Animations has no design-tool pipeline and no runtime player; the motion is expressed as SwiftUI state and modifiers. If your animation is a brand illustration with many layers and a designer owns it, Lottie fits better. If your animation is a button that pulses, a number that cross-fades, or a border that moves via dashPhase, writing it in SwiftUI is a few lines and this repository shows you those lines.

Alternatives and the Android question

There is no Android target here: the README names iOS, macOS, visionOS and watchOS, and every example is SwiftUI. SwiftUI does not exist on Android, so there is nothing here to port directly; the equivalent work on Android would be written against a different UI toolkit entirely. For Apple platforms, the honest alternative to this repository is the Apple Developer Documentation animations section the README itself cites as the basis for most entries, plus the PhaseAnimator, KeyframeAnimator and Spring pages it links. Those give the API contract; this repository gives a worked example with a preview GIF, which is the part Apple's reference pages do not provide. If you want a maintained, versioned abstraction over the same APIs, you need a package, and this repository is not one.

Editorial conclusion

Adopt it as a reference when you want to write a SwiftUI effect yourself and need a working example of a phase animator, keyframe animator, spring or transition to adapt. Do not adopt it if you need a versioned dependency, an API surface to call from your own code, or anything that runs outside Apple platforms: the repository is an Xcode project plus standalone gists, not a package. Before copying anything, open the specific file, check the iOS version its APIs require, and confirm the licence text you are carrying over, since the repository is Unlicense while some entries link out to gists.

Frequently asked questions

Official sources

1. amosgyamfi/open-swiftui-animations on GitHub
2. Issues
3. License: Unlicense
4. Project website
5. README