Anchorage: writing Auto Layout constraints as Swift expressions

Constraints as expressions instead of calls

Anchorage is a lightweight collection of intuitive operators and utilities that simplify Auto Layout code, and it is built directly on top of the NSLayoutAnchor API. The mechanism is deliberately narrow. Each expression acts on one or more NSLayoutAnchors and returns active NSLayoutConstraints, and where the plain API would take a constraint item, a relation and a constant, the library takes the same information and lets you write it as an equation between two anchors. The result is that the constraint you would have written as a call to the equalTo method with a constant now looks like a comparison between two anchors. The library does not replace Auto Layout, does not introduce a layout model and does not add a view or a container of its own. The audience is an iOS team already committed to NSLayoutAnchor and tired of the boilerplate that comes with it, and the honest framing is that Anchorage is a syntax layer rather than a system.

Alignment, relative alignment and sizing

The core syntax covers the cases you write most often. A leading edge pinned twelve points from the container is written as an equality between the leading anchor and the container's leading anchor plus twelve, and a trailing edge that must stay at least twelve points away uses the less-than-or-equal operator. Centring is expressed against the center anchor, and there is a plural form that centres both axes at once. Relative alignment goes further and divides by a factor, so a view can be centred at two thirds of the container's width, or a top edge placed at a quarter of the container's height. Sizing follows the same pattern, with a width capped at a hundred points, a size anchor constrained to a fixed CGSize, two views constrained to the same size, and an aspect ratio expressed as a multiple and a division. That last one is worth pausing on, because a ratio written as an equation between a width anchor and a height anchor is the kind of constraint that is tedious in the raw API and is the kind of thing this library exists to make readable.

Composite anchors and the inset convention

Beyond single anchors there are composite ones, which constrain several edges at once, and the library is opinionated about which edges they use. The edge anchors constrain the leading, trailing, top and bottom edges to be equal, and the horizontal and vertical anchors cover one axis each. Two conventions make these composites usable. The first is that horizontalAnchors and edgeAnchors use the leading and trailing anchors rather than left and right, because using leftAnchor and rightAnchor is rarely the right choice, and the README says so directly. The second is the inset rather than shift idea. When you constrain leading and trailing or top and bottom, it is far more common to work in terms of an inset from the edges than to shift both edges in the same direction, and Anchorage handles that for you by flipping the relationship and inverting the constant on the far side of the axis. The result is that the expression you write says what you mean, an inset of ten, rather than describing the arithmetic needed to achieve it.

Priority, storing and batching

Three smaller features make the library practical rather than merely elegant. The first is priority. A tilde operator on the expression sets the priority of the resulting constraint, and the layout priority is an enum with the required value as the default, along with high, low and a fitting size level, though a raw number is also accepted for the custom case. The second is storage. Since the expressions return constraints, you assign them to a variable to keep them, and for a composite expression the result exposes the individual constraints as well as the horizontal and vertical subsets and the whole set. The third is batching. By default the library activates constraints as it creates them, which is fine for a handful, but if you would rather collect them and activate them in one call, the batch function takes a closure and an active flag, so you can build many constraints in a block and then activate the array yourself, or let the library activate them in a batch. The README gives the performance reason for doing it that way.

The autoresizing mask side effect you inherit

There is one behaviour in the library that is not obvious from the syntax, and it is documented in its own section. Anchorage sets the translatesAutoresizingMaskIntoConstraints property to false on the left hand side of the expression, so you should never need to set this property manually. The important caveat is the one the README adds, which is that this matters if the container view relies on that property being set to true. The library's own advice is to keep child views on the left hand side of the expression to avoid the problem, especially when constraining to a system supplied view. This is a real trade-off rather than a free win. The convenience is that a constraint you express against a view usually just works, and the cost is that a view you did not intend to constrain may end up with a different autoresizing behaviour than the one its container assumed. If your layout mixes views that rely on the autoresizing mask, this is the thing to check first when a constraint behaves oddly.

Operator overloads have a compile time cost

The README has a section on compile times, and it is unusually candid for a library. Anchorage overloads a few Swift operators, which can lead to increased compile times, and the project offers a way out. Instead of the double equals, the less-than-or-equal and the greater-than-or-equal, you can use a slash-delimited alternative, so a normal equality becomes a slash-equals-slash form and the same goes for the two inequality operators. The example given is the composite edge anchor expression rewritten with the faster alternative. The mechanism is the standard Swift trick for scoping an overload to a file, and the reason it works is that the alternative operator is not overloaded at all, so the compiler does not have to consider it. That said, the readable syntax is the default and most teams will keep it, so the cost is real for a large codebase. If your build times are already a sore point, the operator scoping is worth knowing about before you decide the library is the cause.

Three ways to install it, and a repository that has moved on

Installation is conventional for a Swift library of this vintage. With CocoaPods you add one line to the Podfile:

pod 'Anchorage'

With Carthage you point the Cartfile at the repository:

github "Rightpoint/Anchorage"

and then run carthage update to build the framework and drag the built Anchorage.framework into the Xcode project. The repository also carries a Package.swift and a .swiftpm directory, so Swift Package Manager is available as a third route, along with the podspec, the Xcode project, a demo application and a test target. The licence is MIT, with the text in the LICENSE file. The version history is where a prospective adopter should pause. The badge advertises Swift 4.2 and 5.0, the newest release tag is 4.5.0 from 2020-10-30, the one before it is 4.4.0 from February 2020 and 4.3.1 from 2019, and the last push to the master branch was on 2026-04-08. In other words the code is old, the syntax is stable, and the branch is not entirely abandoned, but nobody is shipping new versions of it, and you are adopting a library whose last tagged release predates most current Swift toolchains.

Editorial conclusion

Anchorage suits an iOS team that has decided its layouts will be written with NSLayoutAnchor and wants the repetitive part of that API taken away, especially the inset and composite anchor handling. It is a poor fit for a project that wants zero third-party dependencies, since the whole library is operator sugar, and it is a poor fit if compile time is already your bottleneck, which the project itself flags. Before adopting it, check the release history, because the newest tag is 4.5.0 from 2020 while the branch has seen a push in 2026, and decide whether the toolchain versions it was written against still match your project.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. Rightpoint/Anchorage on GitHub