SnapKit's makeConstraints closure and the Xcode 26 floor behind it

One closure produces the entire constraint set

The entry point is a `snp` property on the view, and the work happens inside a closure that receives a builder. The quick start creates a `UIView`, adds it to the view controller's view, sets a background colour, and only then opens the closure:

box.snp.makeConstraints { (make) -> Void in
   make.width.height.equalTo(50)
   make.center.equalTo(self.view)
}

Two chained calls do the whole job: a width and a height fixed at 50, then a centre matched to the parent view. Each chain reads as a statement about one attribute, and the argument to `equalTo` is the value being compared against, a plain number for the size and the superview for the position. No constraint object appears, no activation call follows, and the closure returns nothing.

The DSL only arrives after the view already exists

SnapKit enters after a view has been constructed and placed in a hierarchy. In the quick start, `box` is a `UIView` created lazily, pushed into `self.view`, given a background colour, and constrained last. A view that was never added to a superview has nothing for `make.center.equalTo(self.view)` to match against, so the closure on its own produces no layout.

The alternative is the same layout system written out by hand in UIKit: build each constraint, attach it to the right pair of views, and activate it. SnapKit does not replace Auto Layout, it replaces the bookkeeping around it, which is why it sits inside an ordinary `UIViewController` rather than taking its place. It also draws nothing. The homepage and API reference are hosted at snapkit.github.io rather than kept in the repository, so the documentation you read is whatever that site serves, not a copy matching the version you pinned.

upToNextMajor puts you on 6.x and leaves 5.7.1 behind

Swift Package Manager is the documented install path, and the dependency line is explicit about the range:

dependencies: [
    .package(url: "https://github.com/SnapKit/SnapKit.git", .upToNextMajor(from: "6.0.0"))
]

`.upToNextMajor(from: "6.0.0")` accepts 6.0.0 and anything below 7.0.0. The 5.x line is not a candidate, and no resolution step will offer it back to you. A project sitting on 5.7.1 has to edit that lower bound by hand, and the edit crosses a release gap running from 2024-02-18 to 2026-05-31. The version number is rarely what blocks such an upgrade, though. The toolchain is.

Swift 6 here means toolchain, not syntax

The requirements block keeps three separate things apart. Deployment targets are iOS 14.0+, macOS 12.0+ and tvOS 14.0+. The build tool is Xcode 26.0+. The language is Swift 6.0+, and that line carries a parenthetical reading toolchain, not syntax. Constraint closures written in the DSL compile under an earlier language mode; what will not happen is a build of the package itself with an Xcode older than 26.

A separate warning sits above the table of contents and is easy to scroll past: to use SnapKit with Swift 5.x, be on 5.0.0 or newer. Those two statements pull in different directions, and the version is the resolution. A team whose CI image is still on an older Xcode cannot build 6.0.0 through Swift Package Manager, and the README does not document a fallback build for that case, so the upgrade stops being a dependency edit and becomes a toolchain upgrade for every target in the workspace.

The requirements list has no watchOS or visionOS line

iOS, macOS and tvOS each get a version floor, and the shape of the list reads as exhaustive rather than illustrative. watchOS is absent, and so is visionOS. If your app ships a watch target, there is no documented floor to plan against and no statement about whether the package resolves for that platform, so the answer arrives at resolution time rather than in the documentation.

The repository layout repeats the gap from the other side. The top level holds Example-iOS and CodeSnippets, and no example macOS or tvOS project, so of the three platforms with declared minimums only iOS ships with a sample application you can open. Two of the three named platforms are supported on the strength of a version number in a list.

The default branch is develop, so a clone is not 6.0.0

The default branch is develop. A plain clone to read the source or to vendor files by hand therefore brings you the development line rather than the 6.0.0 tag, and the README gives no instruction about matching a clone to a release. For an SPM consumer this is irrelevant, because the package manager resolves a version and not a branch, but it changes what a reader auditing the code is looking at.

The root shows what the project ships: Sources and Tests for the code, Package.swift for the manifest, Supporting Files, an Xcode workspace, Example-iOS, CodeSnippets, CONTRIBUTING.md, ISSUE_TEMPLATE.md, and a .travis.yml left over from the Travis era that the README's build badge still points at. Nothing in the README describes how a release is tagged, or what happens to the default branch afterwards.

A Manually section with no snippet, and docs off the repository

Beside the package manager route the README keeps a Manually section, addressed to people who would rather not use a dependency manager at all. The text states that SnapKit can be integrated manually and stops there: no snippet, no list of files to copy, no framework to drag into a project. A team that cannot use Swift Package Manager is left to work the layout out from Sources and Supporting Files by itself.

Help follows the same split between repository and elsewhere. Bugs and feature requests go to issues, contributions go to pull requests, general questions go to Stack Overflow under the snapkit tag. The API documentation and the F.A.Q. are links out to snapkit.github.io, so there is no documentation copy in the tree to read at the tag you depend on.

Two patch releases, then two years of silence, then 6.0.0

The release list runs 5.7.0 on 2023-12-31, 5.7.1 on 2024-02-18, and then 6.0.0 on 2026-05-31, with the last push to the repository on 2026-07-13. Two releases inside two months, a gap of more than two years, then a major. Nothing in the README explains the gap, and the table of contents reserves a Migration Guides section without saying what a 5.x to 6.x upgrade actually changes.

Plan on a major upgrade bringing work rather than a version bump, and treat the branch named develop as whatever followed 6.0.0. SnapKit is released under the MIT licence, and the credits name Robert Payne as the original author alongside many other contributors.

Editorial conclusion

Use SnapKit if your team writes UIKit, wants constraints expressed as chained closures, and can build on Xcode 26. Do not take it if you are still on the 5.7.1 line and cannot move the whole project forward, or if you need a documented watchOS floor. Before adopting, check the deployment targets of your own app against iOS 14.0+, and note that the README's table of contents lists Migration Guides but the README has no such section, so budget time to work out the 5.x to 6.0.0 changes yourself.

Frequently asked questions

Official sources

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