MRTK3: the third generation of the Mixed Reality Toolkit for Unity

A third generation, and what changed underneath

MRTK3 is the third generation of the Mixed Reality Toolkit for Unity. It is an open source project designed to accelerate cross-platform mixed reality development in Unity, and it is built on top of Unity's XR Interaction Toolkit and OpenXR.

The relationship to the previous generation is stated plainly. This new generation of MRTK is intended to be faster, cleaner, and more modular, with an easier cross-platform development workflow enabled by OpenXR and the Unity Input System. Those four adjectives map onto four concrete changes.

On the architecture side, it is built on Unity XR Interaction Toolkit and the Unity Input System, it is dedicated to OpenXR with flexibility for other XRSDK backends, and it supports open-ended and extensible interaction paradigms across devices, platforms and applications. The foundation being Unity's own interaction toolkit rather than a bespoke one is the single biggest change in how the toolkit is maintained, because it means the parts of the stack Unity updates are the parts MRTK3 does not have to maintain itself.

On performance, the claim is that most features and systems were rewritten and redesigned, from UX to input to subsystems, with zero per-frame memory allocation and tuning for maximum performance on mixed reality devices and other resource-constrained mobile platforms. Zero per-frame allocation is the specific claim worth noting, because allocation in a per-frame loop is what causes garbage collection hitches in an XR application, and a visible stutter in a headset is a much worse experience than the same stutter on a flat screen.

The organisation behind it is the Mixed Reality Toolkit Organization, which maintains MRTK3, released MRTK3 for general availability, and will announce future releases. The licence is BSD 3-clause, the primary language is C#, the default branch is main, and the last push was on 2026-10-16.

The package layout is the architecture

The repository is not a single package. It is a set of them, and the list is the clearest description of what the toolkit covers.

The table of packages names twelve of them: Audio Effects, Core Definitions, Diagnostics, Extended Assets, Input, Spatial Manipulation, Standard Assets, Tools, UX Components, UX Components (Non-Canvas) and Windows Speech, each with its own directory at the repository root and its own changelog file. The directories confirm the naming, with names like `org.mixedrealitytoolkit.core/` and `org.mixedrealitytoolkit.uxcomponents.noncanvas/` sitting alongside `org.mixedrealitytoolkit.data/` and `org.mixedrealitytoolkit.uxcore/`.

The split is finer than it first appears. UX Components and UX Components (Non-Canvas) are separate packages, and the repository also carries uxcore and data directories that are not in the package table, which suggests the set of packages in the table and the set of directories in the tree are not quite the same thing. Core Definitions, distinct from Input, means the toolkit separates the types and interfaces that everything else agrees on from the behaviour that acts on them.

Diagnostics being its own package is a small thing that tells you something. A diagnostics package that can be excluded from a shipping build is worth having on a headset, where the difference between a debug overlay and no overlay is a real amount of work for the target device.

Each package directory carries its own CHANGELOG.md, which is what makes the per-package versioning in the release list possible. And the release list shows how that versioning works in practice. The latest listed release, theming-v1.0.0-pre.1, names a set of packages with their versions: Core v4.0.0-pre.3, StandardAssets v3.3.0-pre.1, Theming v1.0.0-pre.1, UXComponents v4.0.0-pre.3, UXCore v4.0.0-pre.3.

So packages move independently. Theming is at 1.0.0 while Core is at 4.0.0, and StandardAssets is at 3.3.0. A consumer can therefore take a new theming package without taking a new Core, which is the practical payoff of shipping the toolkit as packages rather than as one assembly, and it is why the release tags carry a list of package and version pairs rather than a single number.

Early preview, and what that designation costs you

Some parts of MRTK3 are at earlier stages of the development process than others, and the project is explicit about how to spot them. Early preview packages can be identified in the Mixed Reality Feature Tool and Unity Package Manager by the `Early Preview` designation in their names.

At the moment there is one in that state, Accessibility, with its own package directory `org.mixedrealitytoolkit.accessibility/` and its own changelog.

The warning about them is worth reading carefully rather than skimming. It is important to note that the packages may not contain the complete feature set that is planned to be released or they may undergo major, breaking architectural changes before release.

So an early preview package carries two specific warnings. It may be missing features that are planned, so you cannot treat its current surface as the final API. And it may be restructured in a breaking way, so code written against it may need rewriting when it ships properly.

That is a reasonable trade for a package that is still being designed, and the project asks for feedback rather than pretending the work is finished. We encourage you to provide any and all feedback to help shape the final form of these early preview features.

Accessibility being the one in early preview is worth noting on its own. It is the package a project would reach for when it needs a headset application to work for more users, and the fact that it is the least settled part of the toolkit tells you something about where the organisation's remaining work is concentrated.

The other version markers in the release list are the pre-release suffix on the version number itself, with core-v4.0.0-pre.2 and core-v3.3.0. The presence of a 3.3.0 release alongside 4.0.0 pre-releases means the 3.x line was still being released after the 4.x line entered preview, which is the sensible arrangement for a toolkit with a large installed base and a long-lived game or application built on it.

Installing it as dependencies rather than a template

The Getting started section is short, and it contains a recommendation that matters more than it first appears.

The instruction is to follow the documentation for setting up MRTK3 packages as dependencies in your project. Alternatively, you can clone the repository directly to experiment with the template project. However, the project strongly recommends adding MRTK3 packages as dependencies through the Feature Tool, as it makes updating, managing and consuming MRTK3 packages far easier and less error-prone.

The reason is the package structure discussed above. If the toolkit is eleven or twelve packages with independent versions and independent changelogs, then vendoring the source into your project means you are now responsible for merging upstream changes into your copy of each one. Adding them as dependencies through the Feature Tool means Unity Package Manager handles the resolution, and updating a package is a version bump rather than a merge.

That is a meaningful difference for a project that will live for years, and it explains why the repository can carry so many packages without becoming unmanageable.

The template project is still there and is explicitly offered as the way to experiment, so there is a low-commitment path for evaluating the toolkit before committing to the dependency route.

The long term support section sets the floor: OpenXR, Unity 2022.3 LTS, and Unity's XR Interaction Toolkit 3.0 as minimum requirements. That is a meaningful set of constraints. Unity 2022.3 LTS means an XR project on this toolkit is on a long-term-support release rather than the latest one, and requiring XR Interaction Toolkit 3.0 rather than the 2.x line means the interaction layer underneath is the newer API generation.

The user interface improvements are the part a designer will care about most: new interaction models such as gaze-pinch indirect manipulation, an updated Mixed Reality Design Language, Unity Canvas plus 3D UX with production-grade dynamic auto-layout, unified 2D and 3D input for gamepad, mouse and accessibility support, and data binding for branding, theming, dynamic data and complex lists.

The device list, the UX blocks and the project files

The supported devices table is the honest answer to the question most people have about an XR toolkit, which is whether it will run on the device they have.

For OpenXR devices the list is Android XR, Microsoft HoloLens 2, Meta Quest, Magic Leap 2, Lenovo ThinkReality A3 with Qualcomm Snapdragon Spaces, Windows Mixed Reality as experimental, SteamVR as experimental, and Varjo XR-3 as experimental. On Windows there is the traditional flat-screen desktop, also marked experimental.

The distribution of labels is informative. HoloLens 2 and Meta Quest carry no experimental marker, and the flat-screen desktop does, which tells you that the primary targets are standalone headsets while the flat-screen path is there for development.

The list ends with an invitation rather than a wall: if your OpenXR device already works with MRTK3, let us know. That is a request for coverage data rather than a claim of completeness, and it is the sort of line that appears in a project whose support matrix is driven by what users report.

The UX building blocks section is a table of components, each with an image, a name and a one-line description. Button is a volumetric button optimized for a wide range of input modalities, including poking, gaze-pinch, ray interactions, mouse click and gamepad. Bounds Control is intent feedback and precision manipulation affordances. Object Manipulator moves and manipulates objects with one or two hands across a wide variety of input modalities.

Then the menus and controls: Hand Menu is a hand-anchored collection of UX controls for easy access to quick actions. Near Menu is a collection of UX controls that can be manipulated, pinned and set to follow the user. Slider adjusts a value along a one-dimensional axis. Solver covers object positioning behaviours such as tag-along and body-lock.

The Hand Menu and Near Menu distinction is the interesting one, since it is a design decision rather than an implementation detail. Hand-anchored means the controls live on your hand and travel with it, and pinned and follow-user means the menu is a spatial object you can place. That is the difference between a quick-access overlay and a piece of scene furniture, and both exist because different applications want different things from a menu.

The repository root tells you this is an organisation rather than one package. There is a CODEOWNERS file, a CODE_OF_CONDUCT.md, a CONTRIBUTING.md, a GOVERNANCE.md, a MAINTAINERS.md and a DEPENDS.md, alongside the package directories, plus a `Pipelines/` directory for the build, a `Tooling/` directory, `UnityProjects/` for the sample scenes, a `docs/` directory for the documentation and a `contributions/` directory. There is also a `cgmanifest.json`, which is the file that records the hashes of the third-party dependencies used in the build.

Editorial conclusion

Adopt MRTK3 if you are building an XR application in Unity and want the interaction models, the design language and the UX building blocks already worked out, since that is what the package set covers. Do not adopt it if you are still on MRTK2, because this is a separate generation with its own package layout and its own minimum requirements, and check first which of the packages you actually need, because several of them are still marked early preview and may change in breaking ways before release.

Frequently asked questions

Official sources

1. Issues
2. License: BSD-3-Clause
3. MixedRealityToolkit/MixedRealityToolkit-Unity on GitHub
4. README
5. Releases