Blueprint: Square's declarative UI layer for UIKit, built before SwiftUI

View hierarchies described as values, not as view objects

Blueprint's core claim is that you define a UI hierarchy as pure values, Swift structs and enums, and then the library displays it and updates it as application state changes, including animated transitions. The smallest example is one line.

let view = BlueprintView(element: Label(text: "Hello from Blueprint!"))

Read that carefully, because it explains the whole design. A Label is not a UIView, it is a description of one, and BlueprintView is a UIView that renders that description. Because the description is a value, it can be compared, diffed and stored, which is what makes the update path possible at all. The README frames the benefit as simplifying the task of building and updating views as application state changes. This is the same idea SwiftUI popularised, arrived at in Swift and for UIKit several years earlier, and understanding that ordering is what makes the library's remaining differences legible.

A complement to UIKit with an escape hatch, not a replacement

The README is emphatic that Blueprint is not a replacement for UIKit, and that it was designed as a complement to the platform's tools from the beginning. It can manage the display of a single view controller, or of a single view representing a small part of the screen, and it is straightforward to host standard views and controls within a blueprint hierarchy, always leaving you with an escape hatch. That is the honest framing for adoption. This is not a rewrite-your-app library. The escape hatch runs both ways in practice, because you can drop a UIKit control into a blueprint element and let the rest of the tree stay declarative. The cost is that you now have two ways of building views in the same app, and the boundary between them is a design decision your team has to make and document.

When to keep conventional UIKit instead

The README also names the case where you should not reach for this. Use Blueprint any time you want to display a view hierarchy but do not want to manage view lifecycle, which the README calls a large portion of most conventional UIKit code. But there are times when you do want to manage view lifecycle, and complex animations and transitions are the example given, and for those cases it suggests sticking with a conventional approach. That is a specific and believable limitation rather than a vague caveat. Blueprint's automatic update path is a diff-and-apply model, and when the animation itself is the point rather than a side effect of a state change, you want direct control over the transition. The transitions documentation is a separate reference page in the documentation set, which suggests the animated update path is a first-class feature, but it is also the area where you will need to read rather than guess.

Blueprint inside SwiftUI, but never the other way round

The SwiftUI relationship is asymmetric and the README is explicit about why. The two serve similar purposes and SwiftUI has heavily influenced Blueprint's API, but Blueprint predates SwiftUI and works a bit differently. You can host a BlueprintView in SwiftUI to embed Blueprint within SwiftUI, and you can use the provided ElementView to create Xcode previews of Blueprint. The reverse is not offered, and the reason is structural rather than a missing feature. SwiftUI is hosted by a UIViewController, while Blueprint is hosted in a UIView, so embedding SwiftUI inside Blueprint is not possible with that arrangement. The practical implication for a team mid-migration is that Blueprint can live inside a SwiftUI app, but a SwiftUI screen cannot be dropped into a Blueprint tree.

Three modules, and the split tells you what is core

The package ships three modules, and reading them is a quick way to understand the layering. BlueprintUI contains the core architecture and the layout types, which is the part you always need. BlueprintUICommonControls includes elements representing some common UIKit views and controls, so you are not writing an element from scratch for every button. BlueprintUIAccessibilityCore provides accessibility infrastructure for component authors, which is a separate concern deliberately not mixed into the core. That last module is worth a note: accessibility is a recurring source of bugs in custom view hierarchies, and making it a first-class module with its own infrastructure tells you the project treats it as a component author problem rather than an app author problem.

Adding the package, and the local development setup

Consumption is through Swift Package Manager, and the README shows the dependency entry for your own package.

dependencies: [
    .package(url: "https://github.com/square/Blueprint", from: "5.1.0")
]

In Xcode 11 and later you can add it through the File menu under Swift Packages and Add Package Dependency, giving the git URL when prompted. For local development the project uses Mise and Tuist to generate an Xcode project, and the README walks through it for zsh.

brew install mise
echo 'eval "$(mise activate zsh)"' >> ~/.zshrc
source ~/.zshrc
mise trust
mise install
tuist install --path SampleApp
tuist generate --path SampleApp

The two tools split the work: Mise pins the toolchain and installs dependencies, while Tuist generates and opens the Xcode project. The repository root backs this up with a .mise.toml, a .swift-version, a .swiftformat configuration, a SampleApp directory, a Scripts directory, a generate_docs.sh, a .jazzy.yaml for API docs, a .bk.yaml, a Gemfile with a .ruby-version, and a RELEASING.md.

Active maintenance under Apache-2.0, with documentation as a first-class artifact

The project is maintained. The repository is not archived, the last push was on 2026-10-06, and the release history shows 6.8.0 on 2026-07-09, 6.7.3 on 2026-06-17 and 6.7.2 on 2026-06-16, so patch and minor releases are landing regularly. The licence is Apache 2.0, with the full notice in the README and the LICENSE file at the root, and the copyright is Square, Inc. from 2019. The CI setup is visible in the badges: a tests workflow, a lint workflow and a workflow that generates and publishes documentation, which matches the repository contents and the jazzy configuration. The documentation set is genuinely thorough for a library README. There is a getting started sequence covering Hello World, the element hierarchy, building custom elements and layout, a reference section for Element, BlueprintView, ViewDescription and Transitions, and two tutorials, one on using Blueprint in a view controller and one on building a receipt layout.

Editorial conclusion

Blueprint fits an iOS team with a large UIKit codebase that wants a declarative way to describe view hierarchies, particularly for complex layout work such as receipt rendering, and that has people who know the library. It does not fit a new project starting in 2026, since SwiftUI covers the same ground with platform support, and it does not fit work that needs the two systems embedded in each other. Verify first whether your team still ships UIKit, read the transitions documentation before you rely on animated updates, and check the CHANGELOG for the version you pin, since the API is stable but the module split has changed over the releases.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. square/Blueprint on GitHub