apple/swift-algorithms: chunked, combinations and the rest of the Algorithms package

What the Algorithms package adds to the Swift standard library

Swift's standard library covers the common cases: map, filter, reduce, sorted. It does not ship chunking, combinations, permutations, cycling or random sampling as first-class operations. apple/swift-algorithms fills that gap as a separate SwiftPM package rather than a language change, which means you opt in per project and pay nothing when you do not.

The audience is Swift developers who already have a sequence or collection and want a named operation instead of a hand-written loop. The README frames the package as "a variety of sequence and collection operations, letting you cycle over a collection's elements, find combinations and permutations, create a random sample, and more." That is a library for everyday collection work, not a data structures textbook: the topics on the repository are algorithm, iterator and itertools, and the module is called Algorithms.

How chunked and the other operations actually work

The package is built on Swift's Sequence and Collection protocols, so an operation is a method on a value you already have, not a free function you pass data into. The README's first example is chunking, described as a group of methods that break a collection into consecutive subsequences. One variant takes a closure comparing adjacent elements and returns the breaking points; the README uses it to split an array into ascending runs.

let numbers = [10, 20, 30, 10, 40, 40, 10, 20]
let chunks = numbers.chunked(by: { $0 <= $1 })
// [[10, 20, 30], [10, 40, 40], [10, 20]]

A second variant keys off a transformation of each element instead of a pairwise comparison. The README groups names by first character with `chunked(on: \.first)`, producing `[["Cassie", "Chloe"], ["Jasmine", "Jordan"], ["Taylor"]]`. The difference matters: `chunked(by:)` decides boundaries from the relationship between neighbours, while `chunked(on:)` decides them from a value derived from each element alone. Choosing the wrong one gives you subtly wrong groups rather than a compile error.

The related types in the package are the lazy wrappers and iterators that back these methods. That is why the repository lists iterator among its topics: many operations return a view over the original collection rather than an eagerly built array, and you convert to an array when you want the materialized result.

Adding apple/swift-algorithms to a Package.swift

The README gives the dependency line directly. Add it to the dependencies array in your `Package.swift`, pinned from version 1.2.0:

.package(url: "https://github.com/apple/swift-algorithms", from: "1.2.0"),

Then declare the product on the target that needs it. The README shows the product name as `Algorithms` and the package name as `swift-algorithms`, and both strings have to match exactly:

.target(name: "<target>", dependencies: [
    .product(name: "Algorithms", package: "swift-algorithms"),
]),

Finally, import the module in the source file where you use it. After `import Algorithms`, the chunking call above compiles as written. If the build fails on an unresolved product, the usual cause is a mismatch between the product name and the package name in that `.product` line, not a missing dependency.

The README points to API documentation hosted on the Swift Package Index, and the repository carries a Guides directory with longer write-ups per operation. Those are the places to look before writing your own version of something the package already exposes.

Where the package is the wrong choice

The README is explicit that the package is source stable and follows Semantic Versioning, with breaking changes to public API only in a new major version. But it immediately qualifies that: "from time to time, we expect that new versions of this package will require clients to upgrade to a more recent Swift toolchain release," and requiring a new Swift release only needs a minor version bump. A `from: "1.2.0"` constraint therefore does not protect you from a toolchain requirement arriving in 1.3.0 or later. If you ship a library that other teams build against an older Swift, that is a real constraint to plan for.

The second boundary is scope. This is a collection-algorithms package, not a general utility belt. It does not replace Foundation's date, string or formatting APIs, and it is not a data structures library: the README describes sequence and collection operations and their related types, and the repository's topics do not include graphs, trees or priority queues beyond what the operation list covers. If your problem is choosing a data structure rather than transforming a sequence, this package is not the answer, and the search phrase "swift algorithms and data structures" describes a different kind of resource.

The third is the public API surface. The README defines it narrowly: non-underscored declarations marked `public` in the `Algorithms` module. Anything underscored, and anything outside that module, may change in any release, including a patch release. Reaching into internals to get a behaviour you want is a maintenance liability, not a shortcut.

Alternatives and the difference in approach

The most direct alternative is the Swift standard library itself. Its collection methods are stable, always available, and require no dependency, but they cover a smaller set of operations. Writing chunking by hand with an index loop is straightforward; writing combinations correctly, with the right laziness and ordering guarantees, is not. The trade is a dependency line in `Package.swift` against code you own and test yourself.

A second alternative is a third-party algorithms package, including ones distributed through CocoaPods. The search phrase "swift algorithms pod" reflects that habit. The difference is provenance and versioning policy: apple/swift-algorithms is maintained under the apple organization with a stated source-stability contract and a published changelog, while third-party packages set their own rules. That contract is the actual product here. If you need a guarantee about when your build can break, the README's versioning section is the thing to read, and it is the reason to prefer this package over a copy-pasted snippet.

Maintenance, versioning and licence

The repository is not archived, and the last push was on 2026-07-22. Releases are infrequent rather than continuous: 1.2.1 landed on 2025-02-10, 1.2.0 on 2023-11-15, and 1.1.0 on 2023-10-05. Two of those three are close together, and then more than a year passes to the patch release. Plan upgrades around releases, not around a rolling cadence.

The upgrade cost is bounded by the source-stability promise for the public API, with the toolchain caveat above. Pin a version in `Package.swift` and read the CHANGELOG before moving the pin; the repository keeps one at the top level alongside the licence header template and the Swift format configuration.

The package is licensed under Apache-2.0, with `LICENSE.txt` at the repository root. Apache-2.0 is a permissive licence that includes an explicit patent grant and requires you to preserve notices. That is a summary of the identifier, not legal advice; check the full text and your own obligations.

Editorial conclusion

Adopt apple/swift-algorithms if you are on a recent Swift toolchain and keep reimplementing chunking, combination or permutation logic by hand. Do not adopt it if you need a frozen dependency across an old toolchain, since the README says a new Swift release can arrive in a minor version bump. Before adding it, read the API documentation and the Guides directory for the operation you need, and confirm the exact version you pin in Package.swift against the CHANGELOG.

Frequently asked questions

Official sources

1. apple/swift-algorithms on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases