# Euclid builds 3D geometry in Swift, from extruded paths and boolean solids

> Euclid is a Swift library for creating and manipulating 3D geometry, with extrusion and lathing of 2D paths and constructive solid geometry for combining or subtracting shapes. It is the implementation behind the ShapeScript scripting language, it runs on every Apple platform as well as Linux and WebAssembly, and it is MIT licensed.

**nicklockwood/Euclid** — A Swift library for creating and manipulating 3D geometry

- Repository: https://github.com/nicklockwood/Euclid
- Stars: 698 · Forks: 58
- Language: Swift
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/nicklockwood-euclid

## Two ways to make a solid, and a way to cut it

Euclid is a Swift library for creating and manipulating 3D geometry, and the description of what it does is short enough to state precisely. It uses techniques such as extruding or lathing 2D paths to create solid 3D shapes, and CSG, constructive solid geometry, to combine or subtract 2D or 3D shapes from one another.

Those are the two halves of a modelling toolkit. Extrusion takes a closed 2D outline and sweeps it along an axis. Lathing, in the sense of a lathe or a revolve, takes a profile and rotates it around an axis, which is how you get a vase, a knob or a rounded housing in one operation. CSG is the boolean algebra on top: union, subtraction, intersection. A shape that is awkward to describe as a profile becomes easy to describe as one solid minus another.

The library is the underlying implementation for ShapeScript, the open source scripting language by the same author, and for the ShapeScript Mac and iOS apps. The README states the consequence in the most useful way it can: anything you can build in ShapeScript can be replicated programmatically in Swift using this library.

That relationship is the key to understanding the API. ShapeScript is a scripting language with a document format, a renderer and a user interface, and Euclid is the geometry engine underneath it. So the Swift API is the shape of the interpreter, not the shape of a game engine, and the types you will meet correspond to the objects the scripting language manipulates.

## The library is funded by an app, and the README says so

The funding model is stated in the introduction rather than hidden in a sponsors file. If you would like to support the development of Euclid, the README suggests buying a copy of ShapeScript. The app itself is free, but there is an in-app purchase to unlock some features, and a PayPal donation link sits in the same paragraph.

It is worth pausing on what that arrangement implies. Euclid is MIT licensed, so the code is free to use, modify and ship, and the donation is a request rather than a restriction. But the practical reality is that the person maintaining the library is the person selling the app, and the app is where the features and the polish live.

For an adopter, the useful inference is that the library is developed backwards from a product. Bugs that users hit in ShapeScript get fixed in Euclid first, which is a decent prioritisation model. The risk is that the library's public API evolves to serve the script interpreter, and the README's own suggestion to consult the documentation for all Euclid types and functions, rather than a getting started guide, hints at that.

The other maintenance signal is the presence of a build badge, a Codecov badge and a CHANGELOG.md, which indicate a project with continuous integration and coverage measurement rather than a one-person hobby.

## Installing through Swift Package Manager or Carthage

Euclid is available as a Swift package or as a dynamic framework that you can import into an Xcode project, and it can be installed manually, with Carthage or with Swift Package Manager.

For Swift Package Manager, the README says to add the package to the dependencies section of your Package.swift file.

```swift
.package(url: "https://github.com/nicklockwood/Euclid.git", .upToNextMinor(from: "0.10.0")),
```

The upToNextMinor requirement pins the dependency to the 0.10 series and allows patch updates, which for a library that reaches a stable 1.0 later may need revisiting. The Carthage route asks for a matching entry in your Cartfile, github nicklockwood/Euclid at about 0.10.0, and Carthage is the older of the two tools, so the Swift Package Manager path is the one to reach for in a new project.

The dynamic framework option matters for projects that are not Swift Package Manager based, for instance a mixed Xcode project that integrates the library by embedding a framework rather than by resolving a package. The documentation covers the manual route alongside the two package managers, and the choice is entirely about how your project consumes dependencies.

## The platform floor is high, and Linux comes along for the ride

The version requirements are stated in one dense note, and each part of it has a consequence.

Building with Xcode requires Xcode 16 or newer. Euclid runs on iOS 15 and later, macOS 12 and later, tvOS 15 and later, watchOS 9 and later, and visionOS 1.3 and later. The Swift package requires Swift 5.10 or newer, and it also supports Linux and WebAssembly, the latter using SwiftWasm.

The Apple platform list is broad, and the watchOS entry is the one that surprises people. A geometry library running on a watch means the operations are expected to be cheap, which is consistent with a design that computes meshes rather than loading them.

Linux and WebAssembly support is the more interesting line, because it comes from the Swift package rather than the framework. A library that has to work on a server or in a browser is pushed towards a self-contained, portable core with no dependency on Apple frameworks, and it means the same geometry code can be shared between an iOS app and a server side renderer. The README also states the platform coverage in a badge covering iOS, macOS, tvOS, watchOS, visionOS, Linux and WebAssembly, which is the same list.

For anyone planning a deployment, the practical check is the floor rather than the ceiling. An app that still supports iOS 14 cannot take the library without a polyfill strategy, and a build server on an older Xcode cannot build it either.

## The CSG engine came from a JavaScript library

The credits section says more about the design than the introduction does.

The framework is primarily the work of Nick Lockwood, and special thanks go to Evan Wallace, whose JavaScript CSG library provided the inspiration for Euclid in the first place, along with the BSP algorithm used for Euclid's CSG operations.

That is a specific and useful piece of provenance. BSP, binary space partitioning, is the classic approach to boolean operations on polygons, and it is well known to have awkward cases: coplanar faces, near coincident vertices and the general fragility of an algorithm that partitions space. A library that inherits an algorithm also inherits its edge cases, and knowing that the approach came from a JavaScript implementation designed for interactive use tells you something about the performance envelope and about which degenerate cases have probably been hit hard.

The rest of the credits cover the surrounding work. Joseph Heck implemented the DocC documentation, Andy Geers contributed several bug fixes and improvements, and Patrick Goley first suggested the name Euclid for the library. The name suits the domain, since Euclid is the traditional reference point for geometry, and it also fits a library whose main operations are about solids.

The documentation itself is DocC based, generated from the source, and hosted at the project's documentation site, with the full documentation for all Euclid types and functions available there.

## The example project shows SceneKit and RealityKit side by side

Rather than a code listing in the README, the project points at an included example project that shows how Euclid is used in conjunction with SceneKit or RealityKit to generate and render a nontrivial 3D shape on iOS, including a volumetric RealityKit example for visionOS.

The example directory makes the shape of that integration visible. There is an EuclidMesh.swift file, which is the bridge between the library's geometry and a mesh the renderers can display, and two view controllers, one for SceneKit and one for RealityKit, showing the same geometry consumed by two different rendering stacks. A VolumetricView.swift covers the visionOS case, and the application shell consists of an AppDelegate, a SceneDelegate, an Info.plist and an asset catalog.

The structure of the example is itself instructive. SceneKit and RealityKit are the older and newer Apple rendering frameworks, and the fact that both are demonstrated means the library sits below the rendering layer, producing geometry that either can consume. The mesh file is the interesting piece, because converting an in-memory geometry description into a renderable mesh is where most of the integration work sits in any engine.

If you are evaluating the library, this example is the fastest way to see the shape of a real use, and it is the project to open before reading the type documentation.

## A repository with performance tests, DocC and a release script

The top level of the repository shows a library that takes its own quality seriously. There is a Sources/ directory for the implementation, a Tests/ directory, and a PerformanceTests/ directory, which for a library doing geometry and boolean operations is the right place to put the effort, since polygon boolean work is exactly the kind of code that degrades quietly as a model grows.

Documentation is a first class part of the tree. There is an Euclid.docc/ directory holding the DocC catalog, a docs/ directory, a docbuild.bash script and a docpreview.sh script for building and previewing the documentation locally. The .swiftformat configuration means formatting is enforced by a tool rather than by reviewers, and the .github/ directory holds the workflows, with the build badge in the README pointing at a build workflow and the Codecov badge pointing at coverage history.

Release handling is scripted as well, with a prepare_release.sh script at the root and a CHANGELOG.md, even though the project has no GitHub releases published. That combination is slightly odd but not unusual: the changelog and the script maintain a release convention, while the distribution of tagged versions happens outside the releases page.

The last push to the main branch was on 2026-10-17, so the library is being worked on, and the licence is MIT with the text in LICENSE.md.

## Conclusion

Euclid suits a Swift developer who needs procedural 3D geometry, either to build a modelling tool or to generate meshes for a game or a visionOS app, and it does not suit someone who wants a general purpose mesh format library or a renderer, since it produces geometry and stops there. Before adopting it, check that your toolchain matches the stated floors of Xcode 16 and Swift 5.10, and read the documentation for the Euclid types rather than expecting the ShapeScript behaviour to be obvious from the Swift API.

## FAQ

### What can Euclid do in Swift?

Euclid creates and manipulates 3D geometry. It can extrude or lathe 2D paths into solid 3D shapes, and it implements CSG, constructive solid geometry, to combine or subtract 2D or 3D shapes from one another.

### How do I add Euclid to a Swift project?

Add the package to the dependencies section of your Package.swift file, using the package url for the repository with an upToNextMinor requirement, or use the Carthage entry in your Cartfile, or install the dynamic framework into your Xcode project. The library is also available to install manually.

### Which platforms and versions does Euclid support?

Building with Xcode requires Xcode 16 or newer. Euclid runs on iOS 15+, macOS 12+, tvOS 15+, watchOS 9+ and visionOS 1.3+, and the Swift package requires Swift 5.10+ and also supports Linux and WebAssembly through SwiftWasm.

### What is the relationship between Euclid and ShapeScript?

Euclid is the underlying implementation for the open source ShapeScript scripting language and for the ShapeScript Mac and iOS apps, so anything that can be built in ShapeScript can be replicated programmatically in Swift with this library.

## Sources

- [Issues](https://github.com/nicklockwood/Euclid/issues)
- [License: MIT](https://github.com/nicklockwood/Euclid/blob/main/LICENSE)
- [nicklockwood/Euclid on GitHub](https://github.com/nicklockwood/Euclid)
- [README](https://github.com/nicklockwood/Euclid/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/nicklockwood-euclid