USDKit: Swift-Native OpenUSD on Apple Platforms

At WWDC 2026, an Apple engineer opened a 3D scene in Swift, noticed a missing oscilloscope on the workbench, pulled the asset in as a lightweight reference, moved it into place, labeled it for assistive technologies, and exported the whole thing seven times smaller, all in a handful of lines of code.¹ That demo is the thesis of USDKit: Apple now ships a system framework that makes OpenUSD a first-class Swift API, not a C++ library you bind to by hand. You load a stage, compose assets together, author data on prims, and export a compressed package, using patterns Swift developers already know.

This post walks the USDKit story from WWDC 2026 session 285, “Discover USDKit and what’s new in OpenUSD.” Everything below comes from that session directly.

TL;DR

• USDKit brings first-class USD support to Swift apps, “with deep integration for RealityKit and Spatial Preview built right in,” and meets both existing USD developers and Swift newcomers where they are.¹
• The core loop is open, modify, export: create a stage with a USDStage initializer or open one with USDStage.open (it throws, so you try), reference assets through Composition, position them with addTransformOperation, then write a compressed exportPackage.¹
• One honest limit: USDKit “does not provide all the schema-specific APIs,” so authoring accessibility means applying the AccessibilityAPI schema and then creating the label and description attributes by name, using the names defined in the specification.¹
• A new USD primitive type, Particle Fields, “is capable of describing Gaussian Splats as well as other representations,” bringing splats into the same scene as meshes and materials for the first time.¹
• Mesh compression plus AVIF texture compression makes the average asset seven times smaller; you get it through the exportPackage API, in Preview, or via the usdcrush command line tool.¹

What changed in OpenUSD this year

Lee from Apple’s Spatial Standards team introduces USDKit at 7:00, after the OpenUSD foundation updates.

USD is the backbone of the spatial experiences Apple builds, and the open source project behind it, OpenUSD, was originally pioneered by Pixar.¹ USD does not work alone. It integrates with MaterialX, originally from Lucasfilm for material descriptions, and new this year, OpenVDB, originally from DreamWorks, which brings volumetric data into the mix.¹ Apple updated all three across its platforms this year, and as a member of the Academy Software Foundation it contributes to projects like MaterialX and OpenVDB directly.¹

The standardization work runs deeper than code. As a founding member of the Alliance for OpenUSD, Apple “helped release the first formal specification for the core of USD, with domain specifications for geometry, materials, and physics already underway.”¹ Those working groups are open, and the session’s pitch to developers is to get involved if they want a voice in how the industry exchanges 3D content.

The most striking primitive-level news is Particle Fields. Gaussian Splats capture a scene “as millions of fuzzy, overlapping particles, each encoding position, color, and opacity to faithfully reconstruct complex real-world environments.”¹ Working with Alliance for OpenUSD partners including NVIDIA, Adobe, and Pixar, Apple introduced Particle Fields as a new USD primitive type that “is capable of describing Gaussian Splats as well as other representations from this rapidly evolving area of research.”¹ The practical payoff: splats now live “into the same scene as your meshes, materials, and other traditional 3D data for the very first time.”¹ The framing is deliberately modest. Particle Fields describes splats and similar representations; it is a container for an evolving research area, not a finished splat renderer spec.

The USDKit mental model

USDKit brings first-class USD support to Swift apps with deep integration for RealityKit and Spatial Preview built in, and the design goal cuts both ways: developers who already know USD find the concepts familiar, and Swift developers new to USD get patterns and paradigms they already recognize.¹

A few USD concepts anchor the API. A Layer is a single data file. Layers combine through a feature called Composition, and a Stage is “the composed result of one or more layers,” your window into the full scene.¹ Everything in a scene is a USD Prim. Each prim has a Schema that defines its type, plus Attributes that “hold the actual data” and Metadata that “describes information about the prim itself.”¹ Those four words, layer, stage, prim, schema, carry the rest of the workflow.

Open, modify, export

The session walks one concrete loop: load a stage, make modifications, and export the result.¹

You can create a fresh stage in memory with “a simple USDStage initializer.”¹ To work with an existing scene, you open it by passing a file URL to USDStage.open. Because that involves file access, “it can throw, so I use try.”¹ With the scene loaded, the engineer traverses the stage hierarchy looking for the missing oscilloscope, finds nothing, and defines “a new transform prim at the path I want it to live at.”¹

Composition is where the design earns its keep. Rather than copying an asset’s data into the stage, you “add a light-weight reference to it.”¹ The asset lives in its own file, or layer, authored by someone else, and you pull it in: “Everyone works on their own piece of the scene, and USD brings it all together,” and any updates the original author makes “automatically show up in my stage too, because I am just referencing in their file.”¹

Positioning the referenced asset uses addTransformOperation, which “takes care of creating the correct attributes on the prim and updating the transform order automatically.”¹ After that the engineer sets the translation value and the asset moves onto the workbench. The pattern matters because it separates intent (move this prim) from the bookkeeping of which transform attributes exist and in what order.

Authoring accessibility, and an honest limit

Apple has “driven the standardization of accessibility metadata directly in USD,” establishing how assistive labels and descriptions are defined on 3D objects across the industry, and built it with flexibility so it can evolve.¹ Because the metadata is native to USD, “you can author it through any USD API,” and Apple added direct support in Blender and Maya to ease adoption.¹

Here is the caveat worth stating plainly. To add accessibility data, you first apply the AccessibilityAPI schema to the prim, which adds the metadata that signals the schema is present. Then, in the session’s words, “Since USDKit does not provide all the schema-specific APIs, I create the label and description attributes directly, making sure to use the correct attribute names as defined in the specification.”¹ So USDKit gives you a Swift-native way to reach into USD, but it does not wrap every schema with a typed API. For schemas it does not cover, you author attributes by name, and you are responsible for getting those names right against the spec. Treat USDKit as a first-class door into USD, not a guarantee of full typed coverage for every schema.

Compression that ships in the export call

High-quality production USD scenes “can grow to many gigabytes in size,” and the ALab scene in the demo is a working example.¹ In collaboration with the Alliance for Open Media, Apple added “a state of the art mesh compression codec capable of reducing mesh sizes by up to 90%.”¹ Combined with existing AVIF texture compression, “the average asset is now seven times smaller, without compromising visual quality.”¹

The codec lives inside the workflow rather than beside it. Compression support is “built right into the exportPackage API”: you pass the output URL to the exportPackage method on the stage, then enable texture and mesh compression through the export options.¹ If you are not writing code, “you can get the same results directly in Preview or through the usdcrush command line tool.”¹ Apple is working with Pixar to bring this compression to the OpenUSD project so the whole ecosystem benefits.¹

Where USDKit meets the rest of the platform

The framework powers experiences that reach well past a single app. Preview on Mac now does essential 3D editing, and Preview and Quick Look “give you a choice of renderer”: RealityKit “brings consistency across Mac, iPhone, iPad, and Vision Pro,” Storm “remains available for those with existing production pipelines needs,” and a brand-new Raytracer targets the most complex scenes with accurate reflections, precise shadows, and physically correct lighting.¹ All three renderers support OpenPBR, “a significant upgrade over USDPreviewSurface that brings richer, more physically accurate materials to your workflow.”¹

Preview integrates with the new Spatial Preview framework on macOS 27, creating a direct connection between your Mac and Quick Look on Vision Pro so edits show up live in your space, with SharePlay bringing a whole team into the same scene.¹ On the web, Safari introduces the Model tag, embedding a USD model that renders interactively on macOS and iOS and, on visionOS, “breaks out of the page and is presented, spatially, right in the user’s space.”¹

USDKit is the recommended path for app developers on Apple platforms because it is system-provided and deeply integrated, and the rest of the session’s experiences are built on top of it.¹ For advanced or cross-platform needs that go beyond what USDKit covers, SwiftUSD provides open source Swift bindings through the Swift Package Manager, and C++ codebases can embed OpenUSD directly as a framework. All three sit on the same foundation, so “your USD files move freely between all of them.”¹

A distinction worth holding onto: this is the programmatic path. Authoring scenes by hand in a visual tool is the job of Reality Composer Pro (see the RealityKit and Reality Composer Pro mental model); USDKit is the API you reach for when code, not a canvas, is doing the work.

How to start

The session composes into a short path you can follow today:

1. Open a stage. Create one in memory with the USDStage initializer, or open an existing scene by passing a file URL to USDStage.open inside a try because file access can throw.¹
2. Compose, don’t copy. Define a transform prim at the path you want, then add a lightweight reference to an external layer so the original author’s updates flow into your stage automatically.¹
3. Position with intent. Call addTransformOperation to create the right attributes and transform order, then set the translation value.¹
4. Author accessibility honestly. Apply the AccessibilityAPI schema, then create the label and description attributes by the names the specification defines, because USDKit does not provide every schema-specific API.¹
5. Export small. Call exportPackage on the stage with texture and mesh compression enabled, or run usdcrush if you are not writing code.¹

FAQ

What is USDKit?

USDKit is a new Apple system framework that brings first-class OpenUSD support to Swift apps, with deep integration for RealityKit and Spatial Preview built in. It exposes USD concepts (layers, stages, prims, schemas) through Swift patterns, so you can open a stage, compose assets, author data, and export, without binding to a C++ library by hand. Apple recommends it as the starting point for app developers on its platforms.¹

How do I load and modify a USD scene with USDKit?

Open a scene by passing a file URL to USDStage.open inside a try (file access can throw), or create a fresh stage with a USDStage initializer. To add an external asset, define a transform prim and add a lightweight reference to its layer rather than copying its data. Position it by calling addTransformOperation, which sets up the correct attributes and transform order, then set the translation value.¹

Does USDKit cover every USD schema?

No. The session states plainly that USDKit “does not provide all the schema-specific APIs.” For accessibility, for example, you apply the AccessibilityAPI schema and then author the label and description attributes directly, using the exact attribute names defined in the specification. USDKit is a first-class Swift door into USD, not a typed wrapper around every schema.¹

What are Particle Fields and Gaussian Splats in OpenUSD?

Particle Fields is a new USD primitive type Apple introduced with Alliance for OpenUSD partners including NVIDIA, Adobe, and Pixar. It “is capable of describing Gaussian Splats as well as other representations” from this research area. Gaussian Splats capture a scene as millions of overlapping particles encoding position, color, and opacity. Particle Fields lets splats live in the same scene as meshes and materials for the first time.¹

How small can USDKit make a USD asset?

A mesh compression codec built with the Alliance for Open Media can reduce mesh sizes by up to 90 percent, and combined with AVIF texture compression the average asset is about seven times smaller without compromising visual quality. Enable texture and mesh compression through the exportPackage API, in Preview, or with the usdcrush command line tool.¹

USDKit is the programmatic counterpart to the visual authoring story in the RealityKit and Reality Composer Pro mental model, and it feeds the same scenes that drive what’s new in visionOS 27 and the broader RealityKit spatial mental model. On the web side, the same USD assets render through the native HTML <model> element that Safari introduced this year. The full series hub is the Apple Ecosystem Series.

References