StereoKit: an XR engine where the first working app is five lines of C#

Five lines from empty project to a rendered model

StereoKit is an easy-to-use open source mixed reality library for building HoloLens and VR applications with C# and OpenXR, and the README says it is inspired by libraries like XNA and Processing, meant to be fun to use and easy to develop with, yet still quite capable of creating professional and business ready software.

The hello world is the whole argument.

using StereoKit;

SK.Initialize();

Model helmet = Model.FromFile("DamagedHelmet.gltf");

SK.Run(() => {
    helmet.Draw(Matrix.TS(Vec3.Zero, 0.1f));
});

Five meaningful lines. Initialize the engine, load a model, and then run a per-frame callback that draws it. The README states that you can actually do most tasks with a single line of code, including UI, and that StereoKit focuses on getting you productive with the least amount of code possible.

The reference to XNA and Processing is the key to understanding the design. XNA was Microsoft's C# framework for games, and Processing is the teaching-oriented creative coding environment. Both are defined by a small API surface where a beginner can write a complete program in a handful of lines without understanding the engine's internals. StereoKit is deliberately in that tradition, and it is aimed at HoloLens and VR applications specifically, not at a general game engine.

The consequence of that design is that the interesting work happens in the engine rather than in your code, which is a good trade for a first application and a bad one for a large system that needs to bend the renderer.

The feature list, and what it implies about the pipeline

The StereoKit Features list is short, and each entry answers a question an XR developer actually has.

Mixed reality inputs like hands and eyes are trivial to access. That is the one that matters most for HoloLens work, because hand tracking and eye tracking are the input models that distinguish a headset application from a flat one, and they are exactly the parts that are tedious to wire up by hand.

There is easy and powerful UI and interactions, which is the second big one, since a headset application without a usable panel is a demo rather than a product.

The asset format support is generous. Model formats are .gltf, .glb, .obj, .stl and .ply, and texture formats are .jpg, .png, .tga, .bmp, .psd, .gif, .hdr, .pic, .qoi, ktx2 and cubemaps. That list covers what DCC tools, photogrammetry pipelines and texture compression tools actually emit, including ktx2 for GPU compressed textures and hdr for high dynamic range environments.

Underneath there is a flexible shader and material system with built-in PBR, a performance-by-default instanced render pipeline, skeletal and skinned animation, physics, and runtime asset loading with cross-platform file picking.

The instanced render pipeline deserves a note because it is the kind of thing that is easy to claim and hard to do. Drawing many copies of the same model is the normal case in an XR scene, whether that is a row of objects, a forest or a crowd, and a per-object draw call makes those scenes fall over. Instancing by default is a design choice with a performance consequence, and the phrase in the list is doing real work.

The last entry is the documentation, which is generated directly from the source code, including screenshots. That is worth noting for a library with a small API, because it means the reference and the implementation cannot drift apart.

The flat screen simulator is the feature that makes it usable

Two features in the list are about the development experience rather than the runtime, and they are the ones that change whether a team can adopt this.

The first is a flat screen MR simulator with input emulation for easy development. This is a desktop mode where the headset application runs as an ordinary window on your monitor, with emulated hands and eyes. For a HoloLens developer, this is the difference between iterating on a build that deploys to a device and iterating on a build that runs on the machine in front of you.

The second is that it builds your application to device in seconds, not minutes. Deployment to a headset over USB, and the round trip through a build and install, is the largest single time cost in headset development. A library that gets into that loop faster is worth a great deal.

The licence question is also answered directly in the FAQ, and the answer is unusual to see spelled out. The MIT License is considered to be a low-friction choice for multiple downstream licensing models, including incorporation into commercial code. That is the entire argument, and it is a good one: an XR engine that cannot be used in a commercial product is a toy, and MIT removes that obstacle entirely.

The FAQ also separates the repository from the product. For the majority of users the getting started guides are the route, and for how to use this repository the answer is that this is where StereoKit's core SDK code resides and the majority of users will not need to use it directly. C# developers rely on prebuilt packages from NuGet, and only if you wish to build StereoKit or the samples from scratch should you look at the build guide.

Platform support, and the architecture table that decides your build

The platform list is broad: Meta Quest, HoloLens 2, Windows Mixed Reality, Oculus Desktop, SteamVR, Varjo, Monado, and essentially everywhere OpenXR is.

The table underneath is the one that determines whether you can ship, and it is worth reading carefully because the answer is per platform and per architecture.

| Platform | x64 | ARM | ARM64 | | Windows (Desktop/Win32) | yes | no | yes | | Windows (HoloLens/UWP) | yes | yes | yes | | Linux | yes | no | yes | | Android | yes | no | yes |

So the desktop Windows, Linux and Android rows all have x64 and ARM64 but not 32-bit ARM, while the HoloLens UWP row has all three.

The README explains the shape of this. Architecture support has focused on 64 bit architectures, with exceptions for certain platforms, and if you require an additional architecture in the NuGet you are asked to propose it as an issue. There is a specific note that UWP's ARM builds much faster than UWP's ARM64, and that WASM only comes in 32 bit flavors.

The WASM comment is the one to hold on to. A 32-bit-only WebAssembly build constrains what you can put in a browser target, and it is a different constraint from the native ones. It is the kind of detail that only appears in a support table.

The table also describes the NuGet package contents, and the README says that StereoKit developers working from C or C++ should be fine to build any architecture from this list of platforms, which is a broader claim for native builds than the binary table supports.

The C and C++ layer, and the language bindings

The repository layout shows a broader surface than a C# library usually implies.

There is a StereoKit/ directory for the main C# assembly, a StereoKitC/ directory for the native C API, an Examples/ directory, cmake/ and tools/ directories, a CMakeLists.txt with CMakePresets.json, and a StereoKit.sln.

The examples are where the language coverage becomes clear. There are StereoKitTest/ for the C# test application, StereoKitCTest/ for the C test, StereoKitCTest_Android/ for the C test on Android, StereoKitV/ and StereoKitZig/, which are the Visual Studio and Zig variants, plus an Assets/ directory and a README.

The Zig and Visual Studio variants are worth noting. A separate C# project for each of those toolchains means the C# API surface is verified against more than one compiler, which catches portability problems early. And a Zig example in a project written primarily in C++ is a statement about the intent of the native layer, which is a C ABI that other languages can bind to.

The dependency list in the README explains what the engine is standing on. OpenXR is the cross-platform XR interface, so the platform coverage above OpenXR is inherited rather than reimplemented. ReactPhysics3D is the physics engine. cgltf handles glTF format support, and meshoptimizer provides glTF decompression and mesh optimization. basis_universal is there for texture compression, and the stb libraries from Sean Barrett handle image and font formats, with QOI adding another image format. miniaudio covers audio playback, and sokol_time provides cross platform high performance time.

The sokol_time entry is not incidental. Timing in an XR application is a correctness concern rather than a benchmark concern, because frame pacing determines whether the thing feels right to wear, and a single time source with consistent behaviour across platforms is what a headset app needs.

A single-maintainer project with a wide surface

The people and process section is short and worth reading for what it implies.

Bugs go on the Issues tab and questions on the Discussions tab. There is a Twitter account for development news, a Discord channel for discussion, help and updates, and a blog for occasional substantial updates. The contributor's guide is at CONTRIBUTING.md, and the README says the maintainers are easily available on the StereoKit Discord and on GitHub.

That last sentence is the honest summary of the governance model. The project is effectively one maintainer, koujaku, with a community around it. That is not a criticism, because for an engine aimed at getting a first application working, a maintainer who answers questions in Discord is often more valuable than a vendor with a support queue.

It does mean something for adoption. The release history shows v0.3.11 from 2025-06-28, v0.3.10 from 2025-02-22 and v0.3.9 from 2024-02-27, and the last push was on 2026-10-13. The version is still 0.3.x, which is consistent with a pre-1.0 engine where the API can still move, and with a project whose releases follow the needs of the maintainer's own applications.

The build system is CMake with presets, and BUILDING.md is the build guide for anyone who wants to compile the SDK or the samples from scratch, which the FAQ explicitly says is the path for a minority of users.

Editorial conclusion

StereoKit suits a developer who wants to put a working AR or VR scene together this afternoon, because the API is deliberately small, the model and texture loaders cover the formats most pipelines already produce, and there is a flat screen simulator so you can build without a headset plugged in. It is the wrong tool if you need fine control over the render pipeline, the native binding layer, or a commercial engine with a support contract, since this one is a single-maintainer project. Before you commit, read the getting started guide for your toolchain, since Visual Studio, VS Code and C or C++ each have a separate path, and check the platform support table, because the NuGet binaries cover a specific set of architectures per platform.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. StereoKit/StereoKit on GitHub