v0.1.0
First release of OCCTSwiftInteraction, the merge of OCCTSwiftTools, OCCTSwiftAIS and OCCTSwiftCADKit into one package vending three targets (ecosystem#42).
Migrating is a manifest change and nothing else
Your import lines do not change. The module names are unchanged, because each is still its own SwiftPM target. Replace up to three dependency entries with one and update the package: label on each product:
// before
occtDep("OCCTSwiftTools", from: "1.6.4"),
occtDep("OCCTSwiftAIS", from: "1.3.2"),
occtDep("OCCTSwiftCADKit", from: "1.1.2"),
.product(name: "OCCTSwiftTools", package: "OCCTSwiftTools"),
// after
occtDep("OCCTSwiftInteraction", from: "0.1.0"),
.product(name: "OCCTSwiftTools", package: "OCCTSwiftInteraction"),Full detail, including which of the eight dependent repos uses what: docs/MIGRATION.md.
Depending on this package does not pull SwiftUI into a headless build. SwiftPM compiles only the targets reachable from the products you name, and OCCTSwiftTools imports no UI framework. That property is what made merging these three safe, and it is enforced by target dependencies rather than convention.
What is in it
Everything the three repos carried at their final versions, plus four pieces of work done since:
- OCCTSwift v3.0.0 across all three targets (ecosystem#39). The six bounding-box accessors that became Optional are unwrapped at every call site, guarding into real failure paths rather than defaulting to a zero-size box at the world origin.
- Face identity is settled as OCCT's
IsSamesemantics (#1). A face shared between two shells is one identity,faces()is the enumeration behindFaceIdentityTable, and a caller needing to know which use of a shared face was picked reads orientation off the returned shape. This also fixed five assertions that had been failing since 2026-08-10, when OCCTSwift 2.0.0 arrived transitively and nothing in CI compiled a test target to notice. - One pick resolver (#2).
OCCTSwiftTools.SubShapePickResolveris now the only place a render-path ordinal becomes aSubShapeRef, andSubShapeRef,SubShapeandInteractiveObjectmoved down toOCCTSwiftToolsaccordingly. Clip-plane awareness, geometry enrichment and the whole-body fallback deliberately stayed in their own layers. - One selection store (#3).
CADViewportServiceused to keep a selection alongside theInteractiveContextit already owned; it now drives that context and projects it.
343 tests across 30 suites, all passing, with swift build, swift build --build-tests, swift-format lint --strict and swiftlint lint --strict clean.
Breaking changes for consumers of the old CADKit
Seven items, listed in full in docs/CHANGELOG-OCCTSwiftCADKit.md. The ones most likely to reach you:
SelectionSummaryis renamedSelectionMeasurements, deprecated alias retained. It never collided with OCCTSwiftUX's same-named type, which is a different thing entirely.selectionModesisInteractiveContext.selectionModerather than a copy, initialised to[.face], overriding the context's[.body]default. The two selections are no longer independent.selectionis ordered by (body id, kind, ordinal) rather than by selection order, since the store is aSet.- Assigning
selectionModesnow clears the selection.
PadCAM's usage keeps working unchanged; its one exposure is that mode default.
Why 0.x
1.0.0 is reserved for when the picking consolidation finishes. Two phases remain, both in other repos: OCCTSwiftUX#29 and OCCTMCP#182. This tag exists so those can start.
Known and unverified: the visionOS/tvOS platform claim is inherited from the Tools and AIS manifests and is untested for the CADKit target, which previously declared only iOS and macOS. Confirm or narrow before 1.0.0.
The three old repositories are archived rather than deleted, so their tags stay resolvable and an unmigrated consumer keeps building until it chooses to move.