SwifterSwift splits 500+ Swift extensions into one file each, so you can depend on a product or copy a single file

One extension per file, with no shared helpers between them

The organizing rule of SwifterSwift is isolation. Each extension lives in its own file and depends only on the standard library and Apple's frameworks, never on another part of SwifterSwift. There are no shared helpers, so any single file can be lifted out on its own.

The layout is predictable: every extension sits at Sources/<Product>/<Type>/<Type>+<Name>.swift. The safe subscript on Collection, for instance, is at Sources/SwifterSwiftStdlib/Collection/Collection+SubscriptSafe.swift. Copy that file into your project and it compiles as is.

This gives three ways to adopt it: the whole library, only the areas you need, or a single copied file. The copy route has a cost that is easy to overlook. A copied file is a snapshot. It no longer receives fixes from the package, and the per-extension test suite stays behind in the SwifterSwift repository rather than coming with it. If you copy more than a handful of files, you have taken on maintenance of a small fork, and depending on the matching product is the cheaper path.

Each Apple framework gets its own product, and unavailable ones compile to nothing

SwifterSwift is modular at the product level. There is one product per area, plus an umbrella SwifterSwift product that includes them all:

SwifterSwiftStdlib and SwifterSwiftFoundation extend the standard library and Foundation on all platforms. SwifterSwiftCoreGraphics covers Core Graphics and Core Animation, and SwifterSwiftCoreLocation, SwifterSwiftMapKit, SwifterSwiftSpriteKit and SwifterSwiftCryptoKit cover their frameworks on Apple platforms. SwifterSwiftUIKit applies on iOS, iPadOS, Mac Catalyst, tvOS, visionOS, and watchOS where UIKit types exist. SwifterSwiftAppKit is macOS only. SwifterSwiftHealthKit covers iOS, iPadOS, macOS, watchOS and visionOS.

Every product builds on every platform. Where a framework is not available, its product is empty. That keeps a multi-platform target from failing to build when it depends on SwifterSwiftAppKit, but it also means a missing extension will not show up as a package error. On iOS, the AppKit product contributes nothing, and the first sign of that is a compiler error at the call site saying the member does not exist. When an extension seems to vanish on one platform, check which product it belongs to and whether that framework exists there.

The umbrella product links HealthKit, which App Review can flag

The convenient choice and the safe choice differ here. The Quick start uses the umbrella product:

.target(
    name: "MyApp",
    dependencies: [
        .product(name: "SwifterSwift", package: "SwifterSwift")
    ]
)

Both SwifterSwift and SwifterSwiftHealthKit link HealthKit. If your app does not use HealthKit, the project's own guidance is to add the individual products you need instead, because App Review can flag apps that link HealthKit without using it.

The consequence is concrete. An app that pulls in the umbrella product for a couple of string or collection helpers inherits a HealthKit link it has no use for, and the problem surfaces at review time, not at build time. For most apps the right dependency list names SwifterSwiftStdlib, SwifterSwiftFoundation and whichever UI framework product applies, and leaves the umbrella product alone. The same choice also keeps the dependency surface proportional to what the app calls.

The UserDefaults privacy declaration does not travel with a copied file

SwifterSwiftFoundation includes a privacy manifest that declares its use of UserDefaults. When you depend on that product, the declaration comes along with it.

The copy route breaks this. If you copy a UserDefaults extension file into your project instead of depending on the product, the manifest stays in the package. You then have to declare the API in your app's own privacy manifest. The file itself compiles without complaint, so nothing in the build reminds you.

This is the main exception to the claim that any file can be copied on its own. The code is self-contained; the compliance metadata around it is not. Anyone using the single-file route should check whether the copied extension touches an API that needs a privacy declaration, starting with anything built on UserDefaults, and add the entry to the app's manifest at the same time as the file. Teams that prefer not to track this by hand have a simple answer: depend on SwifterSwiftFoundation and let its manifest cover the declaration.

Swift 6.2 and iOS 17 are hard floors

The minimum versions are recent. SwifterSwift requires Swift 6.2, which means Xcode 26. Platform minimums are iOS and iPadOS 17, macOS 14, Mac Catalyst 17, tvOS 17, watchOS 10 and visionOS 1.

A project that still supports iOS 16 or builds with an older Xcode cannot take the current package at all. For those projects, copying individual files is the only route, and only for files whose code happens to compile under the older toolchain, which you would have to verify yourself.

Outside Apple platforms, the standard library and Foundation areas also build on Linux, Android, WebAssembly and Windows. The other areas exist there as empty products, as described above. That makes SwifterSwiftStdlib and SwifterSwiftFoundation usable in server-side or cross-platform Swift code, while UIKit, AppKit, MapKit and the rest are Apple-only by nature. If your shared module targets Linux as well as iOS, keep its dependency to those two products.

The install snippet asks for 9.0.0 while the latest published release is 8.0.0

SwifterSwift ships through Swift Package Manager. In Xcode you choose File, Add Package Dependencies, enter https://github.com/SwifterSwift/SwifterSwift.git and select the products. In Package.swift the dependency is:

dependencies: [
    .package(url: "https://github.com/SwifterSwift/SwifterSwift.git", from: "9.0.0")
]

The published releases tell a different story. The latest is 8.0.0 from 2025-08-26, preceded by 7.0.0 on 2024-10-18 and 6.2.0 on 2024-04-05. The repository itself is not archived and was last pushed on 2026-11-02. In other words, the master branch has moved ahead of the last published release, and the installation snippet already points at the next major version.

The practical consequence: a from: "9.0.0" requirement can only resolve once a 9.0.0 tag exists. Until then, use the latest tag that resolves, and expect the per-product layout, the Swift 6.2 floor and the platform minimums described here to reflect the master branch, which may not match what 8.0.0 contains. Check the tag you resolve against the README in that tag.

Every extension carries a Swift Testing suite and a DocC example

Quality is enforced per extension. Every extension has its own Swift Testing suite, covering edge cases such as empty input, Unicode, other locales and time zones. Every extension has a documentation comment with an example, and the full reference is built with DocC and hosted on the Swift Package Index.

The Quick start shows the flavor of the API:

import SwifterSwift

let numbers = [10, 20, 30]
numbers[safe: 3]  // nil

let url = URL(string: "https://example.com/search?q=swift")!
url.queryValue(for: "q")  // "swift"

let frame = CGRect(x: 0, y: 0, width: 100, height: 50)
frame.center  // (50.0, 25.0)

These are small additions to types you already use: an out-of-range index returns nil instead of trapping, a query parameter comes back as an optional string, a rectangle reports its center. That is the whole value proposition, and also its boundary. SwifterSwift extends existing types; it does not add new UI components or architecture. CONTRIBUTING.md holds the rules each extension follows, and the project is MIT licensed.

Editorial conclusion

SwifterSwift suits Swift developers on Swift 6.2 with iOS 17, macOS 14 or newer targets who want small, tested helpers such as Collection[safe:] or URL.queryValue(for:) and are willing to choose per-framework products. It does not suit projects stuck on older Xcode or deployment targets, or apps that add the umbrella SwifterSwift product without using HealthKit. Before adding it, check which version tag your package manager can resolve against the from: "9.0.0" requirement, and pick individual products instead of the umbrella one unless your app uses HealthKit.

Frequently asked questions

Official sources

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