Inferno: SwiftUI shaders you copy file by file, with a few loose ends in its reference

The install is a file copy, even though a Package.swift sits in the tree

There is no dependency to add. To use a shader you copy the appropriate `.metal` file into your project, start from the sample code shown for that shader, and copy `Transitions.swift` as well if you are using a transition shader. The file puts it plainly: the sample project contains a lot of extra helper code to demonstrate all the shaders in various ways, but to use the shaders in your own project you just need to copy the relevant Metal files across. Meanwhile the top level of the repository does hold a `Package.swift`, alongside a committed `Inferno.xcworkspace/` and a `Sandbox/` directory. So the repository is a Swift package with a sample app, while the recommended way to consume the shaders bypasses both.

The frame rate claim covers every supported device and cites nothing

The performance sentence is the strongest claim in the file and the shortest: all the fragment shaders here run at 60fps on all phones that support iOS 17, and 120fps on all ProMotion devices. No device list, resolution or measurement appears with it. The claim is also stated as a property of the shaders rather than of any particular effect, so it covers water ripples, spinning black holes, flashing lights, embossing, noise, and gradients alike. The surrounding text does explain why a per-pixel program is not automatically slow, since a fragment shader runs on every pixel of a SwiftUI view and can transform each one freely.

The type list describes the same vectors two different ways

Eight types are introduced as the ones the shaders use: `bool`, `float`, `float2`, `half`, `half2`, `half3`, `half4`, and `uint2`. Their one-line descriptions are not consistent. `float2` is a two-component floating-point vector, while `half2` is a two-component half-precision floating-point number, and `half3` and `half4` are called floating-point vectors without mentioning half precision. `uint2` is described as a two-component integer vector used to hold X and Y coordinates or width and height, which is the same wording given for `float2`, including the coordinate examples that a two-component integer vector is less obviously suited to than a float one. None of this affects the code, but it is the reference a beginner is told to rely on.

The function reference names a type the project says it avoids

A list of functions follows, alphabetical, from `abs()` and `ceil()` onward, each with a plain-English explanation and a note about vector arguments. The `cos()` entry is the problem: it says that if you provide `cos()` with a vector, for example `vec3`, it will calculate the cosine of each component and return a vector of the same size. No `vec3` appears in the list of eight types the shaders are said to use, which runs `float2`, `half3`, `half4`, and `uint2` instead. The `abs()` and `ceil()` entries use `float2`, which is in the list, while the `distance()` entry also uses `vec2`.

The shaders are compiled by your build, not shipped compiled

Shaders are written in the Metal Shading Language, described as a simple, fast language based on C++ and optimized for GPU operations. The build step matters for the copy-files model: Metal shaders are compiled at build time and linked into a `.metallib` file, and when you activate a shader in your app the corresponding Metal function is loaded from that metallib and used to create a program to run on the GPU. So nothing arrives prebuilt. Copying a `.metal` file means taking on the compilation in your own target, and the metallib reference explains where the shader ends up at runtime rather than offering a faster way to ship one.

Half precision is recommended because occupancy is the stated reason

The performance advice is specific about types. Shaders move between `float`, `float2`, `half3`, and `half4`, and creating a `half4` from a `float` repeats the number across the components. You should prefer `half` whenever the precision requirements allow, for two stated reasons: it saves register space and it increases the so-called occupancy of the shader program, which the file glosses as letting more GPU cores run your shader at the same time. It also states that converting between `half` and `float` is free. The scalar advice is the practical part: `float y = (x - 1) / 2` works but converts integer literals at runtime, so write `float y = (x - 1.0) / 2.0`, with suffixes such as `0.5h` for half and `42u` for unsigned.

Every shader is annotated for someone who does not read shaders

The reason the files are written the way they are stated at the top: the shaders are designed to be easy to read and understand, even for relative beginners, so each line of code is rephrased in plain English and there is an overall explanation of the algorithm at the top of each file. That is the entire premise of the project, and it is the reason the type list, the function glossary, and the scalar warnings exist in the readme at all. It also sets the audience split the file states outright: if you are already comfortable with shaders, download the ones that interest you and get going, and if not, the rest of the readme is a primer for using shaders in SwiftUI.

Nine contents entries have no body, and the license field is empty

The README's contents list names thirteen sections. GitHub records the repository's license as NOASSERTION, meaning it did not identify a standard license, and a `LICENSE` file sits at the top level of the tree alongside `Sandbox/`, `assets/` and `CODE_OF_CONDUCT.md`. Read the LICENSE file itself to confirm the terms.

Editorial conclusion

Inferno suits a SwiftUI developer who wants to read a shader before trusting it, since the plain-English rephrasing and the top-of-file algorithm notes make the collection teachable rather than opaque, and copying one .metal file is a small commitment to try. Two things to weigh. The frame rate claim covers every phone that supports iOS 17 and every ProMotion device with no measurement behind it, so treat it as an expectation rather than a benchmark. And this is source to copy, not a dependency to declare: if your build already centralises shader code, you will be pasting files outside your own structure.

Frequently asked questions

Official sources

1. Issues
2. README
3. twostraws/Inferno on GitHub