kit-app-template: NVIDIA's starting point for building a Kit application or extension

A template repository, and the branch caveat that comes with it

The kit-app-template repository is a toolkit for developers interested in GPU-accelerated application development within the NVIDIA Omniverse ecosystem, offering tools and templates for creating OpenUSD-based desktop or cloud streaming applications with the Omniverse Kit SDK.

The first thing in the README is a feature branch notice, and it is the most consequential line in the document. The repository is based on a Feature Branch of the Omniverse Kit SDK, and Feature Branches are regularly updated and best suited for testing and prototyping. For stable, production-oriented development, the recommendation is the Production Branch of the Kit SDK on NVIDIA GPU Cloud, with the collection linked in the README.

So the template is deliberately pointed at the moving target, not the stable one. That is a defensible choice for a template whose job is to demonstrate current SDK capabilities, and a poor fit if you are copying it into a product with a release schedule. The versioning across two channels also means the template and the SDK have to be kept in step, and the documentation expects you to know which one you are on.

A VERSION.md file at the repository root records the version, and there is a CHANGELOG.md, so the two documents that would tell you what you are actually running are both in the tree.

The use cases the project lists are designing and simulating expansive virtual environments, producing high-quality synthetic data for AI training, and building advanced tools for technical analysis and insights, with cross-platform applications for Windows and Linux, optimized for desktop use and cloud streaming.

What the Kit SDK underneath it is

The template is useless without the SDK, so it is worth being clear about what the SDK is.

The Omniverse Kit SDK enables developers to build immersive 3D applications, and the README lists its key features. Language support means developing with either Python or C++, which is an unusual flexibility for a native 3D framework and the reason a template repository can serve both audiences.

The OpenUSD foundation means using the Open Universal Scene Description for creating, manipulating and rendering rich 3D content. OpenUSD is the format underneath, which is the reason an Omniverse asset can move between tools without losing its scene graph.

GPU acceleration covers the high-fidelity visualisation and simulation side, and extensibility is the part the template leans on most: creating specialised extensions that provide dynamic user interfaces, integrate with various systems, and offer direct control over OpenUSD data.

That last point is why the repository has separate templates for applications and for extensions. An application is a standalone program with its own window and lifecycle. An extension is a unit of functionality that runs inside the Kit runtime, and the extension model is the primary way Kit applications are built, which is why the template treats both as first class.

The SDK is downloaded, not vendored. Internet access is listed as a required prerequisite, for downloading the Omniverse Kit SDK, extensions and tools, so the repository itself is small and the heavy dependency arrives at setup time.

The hardware and driver floor, which is the real constraint

The prerequisites are stated with unusual precision, and the driver version is the line to read.

The operating system must be Windows 10 or 11, or Linux with Ubuntu 22.04 or newer. The GPU must be an NVIDIA RTX capable GPU, with an RTX 3070 or better recommended. And the driver requirement is specific: this update requires driver version >=550.54.15 on Linux, or >=551.78 on Windows. The documentation asks you to verify driver versions before upgrading, and notes that newer versions may work but are not equally validated.

That last clause is the one that should slow a team down. A driver floor with a stated validation boundary means the environment is pinned, and a machine with a newer driver is outside the tested envelope. On a fleet of artist workstations that is a real constraint, and it is the kind of thing that is much cheaper to discover before you start than after.

The required software dependencies follow the platform. On Windows for C++ development you need Microsoft Visual Studio 2019 or 2022 with the Desktop development with C++ workload selected, plus the Windows SDK installed alongside MSVC, and there is an additional document in readme-assets on the Windows developer configuration. On Linux you need build-essential, which includes make, installed with sudo apt-get install build-essential.

Recommended software is for Linux and is about containers: Docker for containerized development and deployment, with the note to ensure non-root users have Docker permissions, and the NVIDIA Container Toolkit for GPU-accelerated containerized work, which requires the installation and configuration Docker steps. And VSCode, or your preferred IDE.

How the repository is laid out and how the SDK gets fetched

The directory structure is documented as a table, and it tells you what the repository is for.

The templates directory holds the template applications and extensions, which is the actual payload of the project. The tools directory holds tooling settings and repository specific local tools. The.vscode directory holds VS Code configuration details and helper tasks, so the editor is configured for the project out of the box. readme-assets holds images and additional repository documentation, including that Windows developer configuration document. And there is an.editorconfig,.gitattributes and.gitignore, plus the LICENSE and the README, which the table labels project information.

The top level of the tree shows the build machinery. There is a premake5.lua, which is the build system generator, along with repo.sh and repo.bat, which are the setup scripts for the two platforms. The repo.toml and repo_tools.toml are the configuration for the repo tool, which is the mechanism for fetching and configuring SDKs, and the way the Omniverse tooling is meant to be driven. A.skills directory at the top level is unusual and worth looking at if you are contributing, since it suggests the project ships some form of agent instructions.

There is also a SECURITY.md and a CHANGELOG.md, and a PRODUCT_TERMS_OMNIVERSE file, which is a separate document from the LICENSE. For a project that NVIDIA distributes under its own product terms, that distinction matters: the code licence and the product terms are separate obligations, and the repository-level metadata lists the licence as a custom one that GitHub cannot classify.

The limits of a template, and the two ways in

The first limitation is the branch situation already described. A Feature Branch of the Kit SDK is updated regularly, which means the template you clone today may not match the SDK you fetch tomorrow, and the project points stable work at a different distribution channel entirely.

The second limitation is the hardware floor. An RTX capable GPU is required, and an RTX 3070 or better is recommended, so this is not something you can develop on a laptop with integrated graphics or on a virtual machine without a GPU. The driver validation boundary tightens that further. For a team whose CI runs on generic cloud instances, there is no obvious path to running this in an automated build.

The third limitation is the scope of what a template gives you. The repository is described as designed to abstract complexity and jumpstart your development with pre-configured templates, tools and essential boilerplate, and it explicitly points elsewhere for a deeper understanding. It is scaffolding, not a framework, and the moment your application stops resembling the template, you are on your own with the SDK documentation.

There are two documented ways in, and they are aimed at different people. The Kit SDK Companion Tutorial offers detailed insights into the underlying structure and mechanisms for those who want to understand application and extension creation. The NVIDIA DLI course, Developing an Omniverse Kit-Based Application, is the beginner friendly introduction, and it needs an account and login.

For adoption, the concrete checks are the product terms and the licence, since both are in the repository root, and the driver version, since that is the requirement most likely to be missed on a machine that already works for something else.

Editorial conclusion

kit-app-template fits a developer starting an Omniverse Kit application who wants the build system, the repository layout and a working extension already configured, and it fits a team prototyping synthetic data generation or technical visualisation. It is a poor fit if you need a stable production target, because the repository is based on a Feature Branch of the Kit SDK that is regularly updated and best suited for testing and prototyping. Before adopting, read the PRODUCT_TERMS_OMNIVERSE file in the repository root and the LICENSE file, since the licence is a custom one that GitHub cannot classify, and decide early whether the Feature Branch or the Production Branch on NVIDIA GPU Cloud is the right base for what you are building.

Frequently asked questions

Official sources

1. Issues
2. NVIDIA-Omniverse/kit-app-template on GitHub
3. README