The Ultraleap Unity Plugin puts hand tracking in an XR project

A Unity package that brings hand tracking into XR

The Ultraleap Unity Plugin is described as empowering developers to build Unity applications using Ultraleap's hand tracking technology, and it includes various assets, examples and utilities to make it easy to design and build applications using hand tracking in XR projects.

That last phrase, in XR projects, tells you the intended use. A hand tracking camera observes the user's hands, and the plugin turns that into something a Unity scene can respond to, so an application can be driven by gestures rather than by a controller in the user's hand.

The plugin is distributed as a Unity package rather than as a source drop-in, and there are two package names in circulation. The main one is com.ultraleap.tracking, published on the OpenUPM registry, and there is a second one, com.ultraleap.tracking.preview, which carries a preview badge in the registry listing. The preview package is the usual arrangement for a package that is stable enough to try but not yet what the project wants to call its default.

The documentation lives outside the repository, at docs.ultraleap.com for the Unity API, with a separate section of XR guidelines. The README is a gateway to that documentation rather than a replacement for it, and the link list at the top of the file points to the developer site, the tracking software download, the camera setup page, the developer forum, a Discord server and GitHub Discussions.

The licence is Apache-2.0, and the repository carries a LICENSE.md with its Unity meta file alongside it.

What you need before the plugin matters

The getting started section lists four prerequisites, and two of them are not software.

First is the latest Ultraleap Hand Tracking Software, which is a separate download from the developer site. Second is an Ultraleap Hand Tracking Camera, which has its own setup process. The plugin is a bridge between that runtime and Unity, so neither the runtime nor the hardware is optional, and a project that expects hand tracking to work on a headset with no camera attached to it is a different design.

Third is Unity. The requirement is Unity 2022.3 LTS or newer, and the README says the packages have been tested to work against 2022.3 LTS and Unity 6.3 with URP and BiRP. So the supported render pipeline story is explicit: both the universal and the built-in pipelines are in scope.

The fourth point is a wrinkle rather than a requirement. The materials shipped are for BiRP, and the user is prompted to convert the material to URP if that pipeline is detected. So the asset set is authored once and converted on the fly, which is convenient but means you should check that the converted materials look right in your render pipeline rather than assuming they do.

There is also a compatibility caveat that the README states plainly: because of the ever changing landscape of package dependencies in Unity, the project cannot guarantee compatibility with every plugin or variant of Unity, but aims to provide support for any LTS versions that are under continuous support from Unity. That is a reasonable scope, and it also means the answer to the question of which Unity to use is the LTS version Unity is still supporting.

Two known issues you will hit if you skip the section

The README flags known issues in the current release, and both are specific enough that you will lose time if you encounter them without warning.

The first is the serious one. Ultraleap tracking with Ultraleap hardware no longer works on a Meta Quest 3 headset running an operating system version above 76, because of changes in which permissions are allowed. The link points at Meta's documentation on prohibited permissions. So the combination of a Quest 3, an OS newer than 76 and Ultraleap tracking does not work, and the cause is on the operating system side rather than in the plugin, which means there is no fix you can apply in the plugin.

That is a hard constraint on deployment, not a bug to report. If a project targets standalone headsets, the operating system version is part of the hardware decision, and the plugin's tracking path has to be verified on the exact operating system image you ship.

The second issue is smaller and macOS only. The client libraries now default to using a different tracking server port, so for hand tracking to work you either change the Server Connection Input mode to PORT, or you set the port in the Server Name Space field to the JSON object with a tracking_server_port key and the value 12345.

The fact that both are listed as known issues in the getting started section, rather than buried in a changelog, is a courtesy worth noticing. It means the maintainers expect people to read this file before filing a bug.

OpenUPM is the recommended install, and it is configured per project

There are several ways to consume the plugin, and the README says the list is not exhaustive. The one it marks as recommended is OpenUPM, described as the easiest way to get up and running, and the one that makes updating packages simple.

The setup is a scoped registry in the Unity project settings, and it is done once per Unity project. In the package manager settings you add a new scoped registry with these details:

    Name: Ultraleap
    URL: https://package.openupm.com
    Scope(s): com.ultraleap

The scope matters. Scoped registries in Unity map a package name prefix to a source, and the com.ultraleap scope is what tells Unity that the tracking packages come from the OpenUPM registry rather than from the built-in registry.

After the registry is added, you open the Package Manager window, go to the My Registries section in the dropdown at the top left of the window, and manage the packages from there. Adding, upgrading and removing all happen in the same place, and the registry entry is the only per-project configuration, which is what makes updates painless later.

The other documented routes are the ones Unity itself provides, and the README links the Unity package manager documentation for each: installing a package from a Git URL, adding a Git dependency, targeting a specific revision, understanding Git locks, and using a local package path, along with the troubleshooting page for the errors Unity produces when any of that goes wrong.

One warning applies to the repository route. If you are sourcing the Unity plugin directly from this repository, you may find that it does not function well with earlier versions of Unity. So copying the source into a project is a path for people who need to modify the plugin, not a shortcut for everyone.

The repository is a Unity package project, not a Unity project

The top-level contents show what kind of repository this is, and it is worth understanding before you clone it.

There is a Packages directory, which is the Unity package layout, a Scripts directory, a Markdown directory holding the documentation and images used by the README, a Doxyfile for generating API documentation, and a LICENSE.md with its Unity meta file, meaning even the licence file is tracked as a Unity asset so it appears correctly in the editor.

There is also a .git-blame-ignore-revs file, which is the mechanism for telling git to ignore commits when you run blame, and it is a sign of a repository with real history that has been reformatted. The .editorconfig and .gitattributes files handle formatting and line endings, and CONTRIBUTING.md describes how to contribute.

The result is that the GitHub repository is a source of truth for a published package rather than an example scene you open in the editor. That is why the OpenUPM route is recommended and why the README points at the Unity package manager documentation for the alternatives.

The version scheme is visible in the release names, which follow the package name and the version together, for example com.ultraleap.tracking with a 7.3.0 release. So the version a user installs is visible in the package identifier, and the release feed is the package feed.

The release cadence, and what it means for a project on this plugin

The published releases are com.ultraleap.tracking 7.3.0 on 2026-02-25, 7.2.0 on 2025-01-20 and 7.1.0 on 2024-09-09. The last push was on 2026-07-07, and the default branch is develop, with the tagged releases on the same repository.

The gap between the release dates is the thing to plan around. 7.1.0 to 7.2.0 is a gap of about four months, and 7.2.0 to 7.3.0 about a year. A project that pins a version and expects security or compatibility fixes on a short cycle will be waiting a long time between them, and a project that wants the newest behaviour has to check what has changed since its version, because the release notes are the only record of it.

The practical pattern for an XR project is to decide deliberately whether to track the preview package or the stable one. The preview package exists precisely for projects that want to be closer to the current state of the work, and the two are published side by side on the same registry, so moving between them is a package change rather than a repository change.

And whatever version you choose, the compatibility caveats still apply. The plugin depends on a separately installed hand tracking runtime and on a camera, it depends on the operating system permissions of the device it runs on, and it is tested against a specific set of Unity versions and render pipelines. A hand tracking feature is one of the more fragile parts of an XR application precisely because it sits on top of a camera, a runtime and an operating system, and this plugin is the layer that has to keep working while those move.

Editorial conclusion

The plugin fits a Unity team building an XR application that needs hands rather than controllers, and that can run the Ultraleap tracking software and a hand tracking camera on the target device. It does not fit a project that has to support a Meta Quest 3 on an operating system newer than 76, because the README states that combination no longer works. Before you plan a build, read the known issues section, since the macOS port change needs a manual setting, and use the OpenUPM scoped registry rather than copying the repository into your project, since the README warns that sourcing the plugin directly from the repository may not work with earlier Unity versions. The project is Apache-2.0 licensed and the last push was on 2026-07-07.

Frequently asked questions

Official sources

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