Unity VR development is where most enterprise XR projects either find their footing or quietly lose six months. We've shipped it across banking, education, healthcare, and museums, and the pattern is consistent: the difference between a build that ships and one that stalls comes down to Unity-specific engineering decisions. Which packages you start from. How you budget frames against the IL2CPP backend. Whether your asset pipeline survives contact with Quest hardware.
This post is a build-floor account of the Unity toolchain itself: the XR Interaction Toolkit, DOTS/ECS, IL2CPP, Addressables, the Unity Profiler, and the Meta XR SDK. We anchor it in two real projects: Immersive Exposure, which shipped early on the Meta Quest App Store, and Iman VR, built for a museum under historical-accuracy constraints. Both lived or died on Unity engineering choices.
How Does the Unity Toolchain Shape What Ships on Quest?
Unity holds roughly 70% of the AR/VR content market and powers the majority of Quest titles, according to Unity's own platform reporting (Unity, 2024). That dominance matters for one reason: on standalone hardware, the engine's own systems, IL2CPP, the scriptable render pipeline, the XR plugin stack, are what actually constrain what you can ship.
Here's the part teams underestimate. The Quest's Snapdragon XR2 has to hold 72 to 90 frames per second with no PC tethered behind it. Across our enterprise builds, the single most common cause of a missed milestone isn't ambition: it's discovering, late, that a chosen Unity rendering path can't sustain that frame budget on-device. The toolchain decisions made in week one quietly set the ceiling for everything that follows.
Citation capsule: Unity powers roughly 70% of AR/VR content and the majority of Meta Quest titles (Unity, 2024). On standalone Quest hardware running at 72 to 90 FPS, engine-level systems, IL2CPP compilation, the render pipeline, and the XR plugin stack are what determine which features are technically feasible to ship.
Each Unity subsystem below carries its own constraint. Read together, they explain why two studios with the same spec ship very different products.
Which Unity Systems Make It Into a Quest Build?
Most enterprise Quest builds ship on a thin, well-understood slice of the Unity XR stack, not the full feature surface. In our experience, the XR Interaction Toolkit plus the Meta XR SDK and a baked-lighting render path cover the large majority of shipped functionality, while the more advanced subsystems wait for phase two. Here is the hierarchy we see repeatedly.
Tier 1, the XR Interaction Toolkit core. The XR Origin rig, controller and hand tracking via the XR plugin, snap-turn and teleport locomotion, and the interactable framework (XRGrabInteractable, XRRayInteractor, sockets). This is the foundation every Unity VR build stands on, and it always ships.
Tier 2, scenario logic and the Meta XR SDK extras. The features that serve the stated objective: hand-tracking interactions, passthrough, scene anchors, assessment tracking, or in the case of Immersive Exposure, high-quality immersive content playback wired through the Toolkit's interaction events. These ship because their business value is legible.
Tier 3, render and comfort polish. URP tuning, spatial audio, baked global illumination, foveated rendering through the Meta XR SDK, comfort vignettes. These frequently get deferred because they consume profiling time, not feature time, and they lose the argument to functional completeness when the schedule tightens.
Tier 4, DOTS/ECS for heavy simulation. When a scene needs hundreds of interactive agents or instanced objects, Unity's Entity Component System and the Burst compiler can hold frame rate where classic MonoBehaviour code cannot. Powerful, but it forces a parallel data-oriented architecture that most teams scope into a later release rather than the first ship. For the wider engineering trade-offs here, see our breakdown of VR development decisions and what gets cut to hit frame rate.
Tier 5, multiplayer via Netcode for GameObjects. Unity's networking stack with Netcode and Vivox voice is a solid starting point. But networked VR adds latency sensitivity, server architecture, and per-user test overhead that consistently push it to phase two.
Tier 6, experimental subsystems. Eye tracking, full-body IK, generative AI-driven scenario adaptation, and persistent cross-session state via cloud anchors. Compelling in a demo. They almost never appear in a first enterprise deployment.
Immersive Exposure: Scoping for Early Delivery
Immersive Exposure is the clearest example we have of scope discipline enabling an early ship. The project is a VR education platform on the Meta Quest App Store, with interactive 3D photography lessons delivered in an immersive community environment.
The client's feedback: "Released early on the Meta Quest app store, meeting expectations. Responds quickly and follows up promptly."
That early release was not accidental. On the Unity side, it came from keeping the architecture deliberately conventional: a single XR Interaction Toolkit rig, baked lighting, and Addressables for the lesson content so that immersive media could be loaded on demand instead of bloating the initial APK. We did not stand up Netcode for GameObjects to synchronise the community room across arbitrary network conditions in release one. We did not build a remote content backend before the core loop was validated on-device. The XR Toolkit setup and the asset pipeline targeted exactly what the learner needed to study photography in VR, nothing speculative.
The toolchain lesson is sharper than the usual "ship an MVP" advice: the early-ship decisions weren't product decisions, they were Unity architecture decisions. Choosing Addressables over a baked monolith, and deferring Netcode, is what kept the build profileable and certifiable on schedule. The teams that miss their dates rarely over-scope the design. They over-scope the Unity systems.
Iman VR: When Constraints Are the Feature
Iman VR presented a different kind of scoping challenge. This was an immersive VR journey through the life of the Prophet Muhammad, built for the International Fair and Museum of the Prophet's Biography. The constraint was not budget or timeline in the conventional sense. It was authenticity.
Museum-grade reconstruction projects operate under a discipline that commercial VR projects rarely encounter: every visual element must be defensible against historical evidence. You cannot add architectural detail because it looks compelling. You cannot fill a scene with ambient objects because it increases immersion. Every element either has evidentiary support or it does not belong.
This constraint forced a scoping model where visual ambition was subordinated to intellectual accuracy. The result was an experience that served its actual purpose, supporting understanding of historical narrative, rather than one optimised for visual spectacle. The lesson for enterprise clients is direct: the most effective VR projects are those where the success criterion is clearly defined before development begins, and where scope decisions are evaluated against that criterion rather than against a general preference for "more."
For more on applying museum-grade thinking to enterprise VR, our post on custom VR experience development and museum lessons for enterprise covers this in depth.
Which Unity Systems Get Cut to Hold Frame Rate?
Roughly 30% of an enterprise VR budget goes to QA and device testing, per industry build accounting we track across our engagements, and that pressure is what forces Unity subsystems out of release one. The cuts aren't arbitrary. They follow the frame budget and the IL2CPP build pipeline.
Real-time lighting and dynamic shadows. Teams that spec real-time lights on Quest almost always fall back to baked global illumination plus light probes. The Snapdragon XR2 cannot afford per-frame shadow passes at 72 to 90 FPS, so Unity's baked GI pipeline does the work offline and the runtime cost disappears.
Netcode for GameObjects. Multiplayer is the single most common Unity system deferred to phase two. Networked VR layers latency tolerance, server authority, and Vivox voice on top of every interaction, and the per-build test matrix it creates rarely survives the schedule.
DOTS/ECS rewrites. When a scene only sometimes needs hundreds of agents, teams keep MonoBehaviour and cap the agent count rather than rebuild on the Entity Component System. The data-oriented rewrite is real engineering, not a setting, so it waits for a release that genuinely needs it.
Addressables-driven remote content. Many projects want scenarios that update without an app patch. Most ship with content baked into the APK and adopt remote Addressables groups later, once the on-device loop is profiled and stable.
Notice the through-line: every cut above is an engine decision, not a design decision. The product spec rarely shrinks. The Unity systems behind it do. For the broader engineering trade-offs, including draw-call budgets and fidelity-versus-frame-rate calls, see our deep dive on VR development decisions and what gets cut to hit frame rate. For requirements-stage scoping before any Unity work begins, the VR project scoping breakdown covers MVP definition and phase-two deferral.
Which Unity Technical Decisions Constrain Scope?
The XR Interaction Toolkit cuts foundational setup by weeks, according to setup time we track against rolling custom input, yet the package you start from quietly fixes the architecture you live with. Several Unity-specific realities decide what is feasible inside a given frame budget, and the earliest choices carry the most weight.
The VR Project Template and the XR Interaction Toolkit accelerate setup considerably, with pre-configured input, locomotion, and device abstraction saving weeks of foundational work. But they also set architectural patterns that are expensive to unwind later. Starting from the wrong template, or layering incompatible packages onto a rig that was never meant for enterprise data integration, creates technical debt that surfaces during QA.
Performance on Quest hardware is the most common forcing function for scope reduction. Holding 90 FPS, the minimum for a comfortable experience, demands disciplined asset budgets, baked lighting, occlusion culling, and material simplification. Photorealistic shaders need light calculations and high-resolution textures that standalone headsets cannot sustain. When the spec calls for photorealism the hardware cannot deliver, the fix is always the same: simplify the materials, never the frame-rate target.
Profile early and profile on-device. The Unity Profiler, the Frame Debugger, and Meta's OVR Metrics tool surface the real cost of a render path on the headset itself, where the editor's numbers lie. Enterprise teams also keep a pinned Unity LTS version for the life of a build, since changing the editor version mid-project can shift IL2CPP and rendering behaviour in ways QA then has to re-verify.
For a direct comparison of Unity against Unreal in enterprise contexts, our post on Unity vs Unreal for enterprise VR training covers the tradeoffs without the marketing gloss.
Framework and Performance Decisions That Shape the Build
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)
What Are the Unity Licensing and Tooling Costs?
Unity Pro or Enterprise is required once an organisation earns or raises over $200,000 a year, per Unity's licensing terms (Unity, 2024), and that seat cost, not the engine itself, is the line most enterprise estimates forget. The XR Interaction Toolkit, Netcode, and Addressables ship free with the editor.
The real money sits in labour and assets, not licences, and full budget bands belong in a dedicated post rather than here. For the $50K-to-$1M+ tiers and what actually drives enterprise VR spend, see our VR app development cost breakdown. On the Unity side, watch two often-missed line items: paid third-party packages from the Asset Store that the build depends on, and the QA hours that IL2CPP build times quietly add, since every Android player build on Quest takes longer to compile and verify than an in-editor play test.
How Should You Configure a Unity Project for Quest?
A clean Unity-for-Quest setup decides most of your frame budget before a single feature is built, and getting the editor configuration right early is cheaper than re-platforming mid-project. Across our enterprise builds, the checklist below is the one we actually run on day one of a new Unity VR engagement.
Player and build settings
- Platform switched to Android, with the Meta XR SDK or OpenXR plugin installed and the other XR plugins disabled?
- Scripting backend set to IL2CPP with an ARM64 target architecture? (Mono and ARMv7 will not pass Quest store submission.)
- Graphics API set to Vulkan, or OpenGLES3 only where a dependency forces it?
Render pipeline and performance
- URP configured with a baked-lighting path, light probes, and occlusion culling enabled per scene?
- Foveated rendering enabled through the Meta XR SDK, and a polygon and texture budget validated against the device, not the editor?
- Comfort handled at the rig level: teleport or snap-turn locomotion and a comfort vignette wired through the XR Interaction Toolkit?
Assets and profiling
- Heavy immersive media moved into Addressables groups so it loads on demand instead of inflating the APK?
- A profiling pass scheduled on-device with the Unity Profiler and OVR Metrics, not just in Play mode?
For the requirements and MVP decisions that sit upstream of this configuration, the VR project scoping breakdown covers what makes the cut before the engine is even opened. For the build-to-store steps that come after it, our Unity Meta Quest shipping guide walks the certification path.
Related Reading
- VR Development - Hub
- Unity WebGL - Hub
- VR Development Decisions and What Gets Cut to Hit Frame Rate
- Custom VR Experience Development: Museum Lessons for Enterprise
- Unity vs Unreal for Enterprise VR Training
- Immersive Exposure - Project Case Study
- Iman VR - Project Case Study
If you are evaluating a Unity VR development engagement and want a direct conversation about what is realistic for your timeline, budget, and use case, not a pitch deck but a build conversation, get in touch with the VVS team. We will tell you what we have shipped before, what is genuinely new territory, and what belongs in phase two.