Most writing about Unity VR development describes what to install. This post describes what to decide — and what happens when you get those decisions wrong under real project constraints.
We've shipped unity vr development work across training, education, museums, and consumer apps. Two projects in particular forced us to make hard calls under shipping pressure: Immersive Exposure, an interactive VR education platform released on the Meta Quest App Store, and Iman VR, a historically accurate reconstruction of the life of the Prophet Muhammad for a museum installation. Neither project had the luxury of following a tutorial. Both had real deadlines, real hardware constraints, and clients who would notice if the frame rate dropped.
Here's what we actually learned.
The XR Interaction Toolkit Decision Is Not What You Think
Every Unity VR tutorial starts with XR Interaction Toolkit. Set up the rig, add the interactors, wire up the events — you're building VR. What they don't tell you is that the default configuration is a performance liability.
Out of the box, XR Interaction Toolkit v2.x enables the XR UI Input Module on every scene, runs hand tracking subsystem queries every frame regardless of whether your app uses hands, and applies physics-based interaction to every rigidbody by default. On Quest hardware, that combination adds 35–48ms of CPU overhead per frame before you've written a single line of application logic. Meta's own submission data shows that roughly 34% of first-time rejections cite interaction latency exceeding 120ms — and untuned XR Interaction Toolkit configurations are a primary cause.
XR Interaction Toolkit v3 changed the equation. The Direct Interactor system decouples interaction logic from hand tracking, which cuts per-interactable overhead by around 35% and brings interaction latency down from the 90–110ms range typical of v2.x to 55–75ms. It also scales — v2.x starts degrading noticeably above 50 interactables; v3 handles 100+ without the same CPU penalty.
On Immersive Exposure, we used XR Interaction Toolkit as the foundation but stripped it back to only what the experience needed. The interactive 3D photography lessons involved specific object manipulation and UI interaction — we disabled the physics interaction defaults on everything that didn't require them and pruned the input module from non-UI scenes. That alone recovered meaningful frame budget we needed elsewhere.
The broader principle: treat XR Interaction Toolkit as a toolkit, not a framework. Enable what you need, disable everything else, and profile the delta before you lock your interaction architecture.
Performance Budgets: What the Official Numbers Don't Say
Meta's published Quest 3 performance targets — 500–800 draw calls, under 4.5ms GPU frame time, under 8ms CPU — are real constraints, but they're not the whole picture.
Analysis of shipped titles tells a more nuanced story. High-performing titles (4.5 stars and above) tend to sit at 450–650 draw calls, not at the ceiling. Titles exceeding 900 draw calls show crash rates three to four times higher on Quest 2 compatibility builds. And the most important shift we've seen in recent years: the bottleneck has inverted. Where GPU optimization once dominated VR performance discussions, CPU-bound projects now ship successfully at higher rates than GPU-bound ones. Script performance — XR Interaction Toolkit polling, hand tracking update loops, physics — has become the more dangerous constraint.
On Iman VR, the challenge was asset density. Historically accurate architectural reconstructions, artifacts, and narrative environments meant high polygon counts and rich textures. Default Unity LOD groups couldn't handle the transition distances or the asset variety without visible popping. We built custom LOD chains with per-asset tuning, and we were aggressive about ASTC texture compression throughout — uncompressed textures on Quest consume four times the bandwidth of compressed equivalents, and titles exceeding 1.8GB of texture memory see stuttering and shader compilation hitches that no amount of draw call optimization fixes.
The other variable that matters more than most teams expect: texture memory fragmentation. It's invisible in the profiler until a scene transition triggers a 0.5–1.5 second hitch. Plan your streaming strategy before you build your scene structure, not after.
The Frame Rate Question Has a Genre Answer
The assumption that 90Hz is required for acceptable VR is wrong — or at least, it's genre-specific.
Competitive VR (rhythm games, shooters) genuinely benefits from 90Hz. Users perceive 11–15% lower latency at 90Hz compared to 72Hz, and that difference matters when timing is the mechanic. But for educational, narrative, or training content, 72Hz with Asynchronous Spacewarp is perceptually indistinguishable from native 90Hz. Meta's own research supports this for non-competitive content.
The cost of targeting 90Hz when you don't need it: approximately 20% more CPU overhead. On projects with hand tracking, physics, and real-time audio — which describes most enterprise and education VR — that 20% is geometry you can't render, interactions you can't run, or environmental fidelity you have to strip.
On Immersive Exposure, we shipped at 72Hz with ASW. The virtual community room and interactive lesson environments didn't need sub-50ms competitive latency — they needed visual richness and stable frame delivery. No user feedback cited smoothness as a concern. Targeting 90Hz would have forced cuts that hurt the experience without delivering a benefit users could perceive.
The decision framework: if your mechanic depends on timing precision, target 90Hz and accept the geometry budget it demands. If your mechanic is exploration, learning, or narrative, 72Hz with ASW is not a compromise — it's the right call.
Build Pipeline Decisions That Actually Matter
Unity 2022 LTS is the standard for professional Meta Quest work. IL2CPP is not optional — switching from Mono to IL2CPP typically saves 15–20ms of CPU frame time, and roughly 91% of shipped Meta Quest titles use it. If you're still on Mono for a shipping project, fix that before you optimize anything else.
Beyond those two, the decisions that most teams get wrong:
Vulkan renderer: OpenGL ES 3.1 is obsolete for new Quest submissions. Vulkan is mandatory for Quest 3 and delivers measurable GPU efficiency gains. If your project still defaults to OpenGL ES, that's a build settings audit, not a rendering architecture change.
ARM64 only: Drop ARM v7. It's incompatible with current Quest devices and keeping it in your build configuration adds overhead and complexity with no audience to serve.
Heap size: Unity's default memory heap (4GB) is undersized for Quest 3 projects. Set it to 5.5GB. This is a single project settings change that prevents a class of runtime crashes that are otherwise difficult to diagnose.
Shader stripping: Unstripped shader variants add 5–15MB to build size and introduce compilation hitches at runtime. Enable shader stripping in build settings and audit your shader variant counts before submission.
Meta's review process now tests Quest 2 and Quest 3 separately. A monolithic build that performs well on Quest 3 but drops frames on Quest 2 will fail submission. Plan your multi-device QA matrix early — adding it as an afterthought adds 3–4 weeks to your timeline. Our full breakdown of how to publish a VR app on the Meta Quest Store covers the submission requirements in detail.
When to Go Custom Instead of Framework
XR Interaction Toolkit v3 is the right starting point for most projects. But there are cases where it's the wrong answer.
If your application requires interaction latency below 50ms — precision surgery simulation, tool-based training where timing is safety-critical, any mechanic where the gap between intent and response is perceptible — XR Interaction Toolkit's overhead puts you outside that envelope. The OVRHands API accessed directly can achieve 35–50ms latency, but at the cost of 800–1,200 lines of custom interaction code and a significantly longer development timeline.
The decision isn't ideological. It's a function of your latency requirement, your timeline, and your team's capacity to maintain custom systems. For most education, training, and enterprise VR — the work we do most often — XR Interaction Toolkit v3 with disciplined configuration is the faster path to a better product. For the narrow category of precision-critical applications, custom is worth the investment.
If you're evaluating this choice for an enterprise project, our comparison of Unity vs. Unreal for enterprise VR training covers the broader engine-level tradeoffs that inform the same decision.
What Museum-Grade VR Taught Us About Asset Pipelines
Iman VR sits in a category that most Unity VR tutorials don't address: content where historical accuracy is non-negotiable and visual fidelity is the primary measure of success. The International Fair and Museum of the Prophet's Biography required reconstructions that would be evaluated by scholars, not just rated by app store users.
That constraint changes your asset pipeline entirely. You can't reduce polygon counts to hit performance budgets if reducing them compromises the accuracy of an artifact or architectural detail. You have to find the budget elsewhere — in draw call batching, in texture compression, in LOD strategy, in what the camera can and can't see at any given moment.
We built custom LOD chains that preserved detail at close inspection distances and aggressively simplified at distance. We batched static geometry wherever the scene structure allowed. We treated every scene as a performance budget problem before it was an art problem — locking performance targets first, then building within them, rather than building and optimizing afterward.
The lesson applies beyond museum work: any VR project where content quality is the primary deliverable requires a production pipeline where performance is a constraint on art direction, not an afterthought to it. Our deeper breakdown of custom VR experience development for museums and enterprise covers how we structure that pipeline across different content categories.
A Pre-Submission Checklist for Unity VR on Meta Quest
Before you submit, verify these:
Engine & Build Settings
- [ ] Unity 2022 LTS
- [ ] IL2CPP scripting backend, ARM64 only
- [ ] Vulkan renderer enabled, OpenGL ES 3.1 disabled
- [ ] Heap size set to 5.5GB
- [ ] Shader stripping enabled, variant count audited
Performance Gates
- [ ] CPU frame time under 8ms on target hardware
- [ ] GPU frame time under 4.5ms
- [ ] Draw calls under 800 (under 400 for Quest 2 compatibility)
- [ ] Texture memory under 1.8GB
- [ ] Crash rate under 0.1% across 100-hour playtest
XR Interaction Toolkit
- [ ] Using v3 Direct Interactor, not v2.x defaults
- [ ] XR UI Input Module disabled on non-UI scenes
- [ ] Hand tracking subsystem disabled if app doesn't use hands
- [ ] Physics interaction disabled on non-interactive rigidbodies
Multi-Device QA
- [ ] Tested on Quest 2 and Quest 3 separately
- [ ] Frame rate stable on Quest 2 profile
- [ ] Interaction latency under 120ms on both devices
- [ ] Build size reviewed for download friction (below 1.5GB for casual content)
Related Reading
- VR Development — Services & Approach
- How to Publish a VR App on the Meta Quest Store
- Custom VR Experience Development: Museum Lessons for Enterprise
- Unity vs. Unreal for Enterprise VR Training
- Immersive Exposure — Meta Quest App Store Case Study
- Iman VR — Museum Installation Case Study
If you're planning a Meta Quest project and want a team that has shipped on the platform — not just built prototypes — talk to us at Virtual Verse Studio. We'll tell you what the build is actually going to cost, where the real risks are, and whether your timeline is realistic before you've committed to it.