TL;DR: An XR app does not stay finished. It sits on top of a headset operating system, a vendor runtime, an engine, a store or device management platform and a specific piece of hardware, and every one of those layers changes on its own schedule, owned by companies that do not know your app exists. Budget for maintenance from the start, make build decisions that keep it cheap (OpenXR where possible, vendor features behind a thin layer, a pinned engine version, a repeatable build), and agree before launch who tests each headset update before your users get it.
Most software ages slowly. A web app that worked last year usually still works, and when it breaks, the cause is normally something your own team changed.
XR apps age differently. A training scenario that ran perfectly at launch can start misbehaving after a headset update nobody on your side requested, a store can reject your next release because a policy changed, and the headset model you standardized on can quietly disappear from the vendor's catalogue. None of this means the build was bad. It means immersive software lives on a stack that moves faster than most, and the cost of keeping it running is a real line item that belongs in the plan, not a surprise in year two.
This piece covers what actually changes under a shipped XR app, the build decisions that make maintenance cheaper, and what a sensible maintenance plan looks like.
Why XR apps need more upkeep than most software
Picture the stack under a typical standalone VR or mixed-reality app:
- The headset operating system, which on most standalone devices updates itself on the vendor's schedule.
- The XR runtime and vendor SDKs that handle tracking, hands, controllers, passthrough, spatial anchors and, on some devices, eye tracking.
- The engine, usually Unity or Unreal, with its own release cycle and its own deprecations.
- Distribution, either a public store with review rules or an enterprise device management platform.
- The hardware itself, which has a commercial life measured in a few years.
- Your own backend and integrations: logins, reporting, a learning system, live data feeds.
A phone app has a similar stack, but the mobile platforms are mature and change cautiously. XR platforms are younger and still moving quickly, and features that matter most to immersive apps, like passthrough, hand tracking and scene understanding, are exactly the ones still evolving. That is the honest reason an XR app needs more attention after launch than a comparable web or mobile product.
What actually changes under a shipped XR app
Headset OS and runtime updates
Consumer-oriented standalone headsets generally update automatically. Most updates are harmless, but some change behavior an app depends on: how permissions are requested, how passthrough is presented, how the guardian or boundary system interacts with your scene, or how hand tracking reports a pinch.
The fix is rarely large. The problem is timing. If the first person to discover the change is a trainee in a scheduled session, the update has become an incident. Enterprise device management platforms can often hold or stage OS updates across a fleet, which is one of the reasons we treat device management as a day-one requirement in our guide to taking XR from pilot to rollout.
Vendor SDKs and deprecations
Headset vendors regularly retire older SDKs and APIs in favor of newer ones, and the industry has steadily moved toward OpenXR, the open standard from the Khronos Group that most major headset makers now support. An app built on an older proprietary path will eventually need migrating, and that migration is far easier when the original build kept vendor-specific code in one place.
Some capabilities are still vendor-specific even under OpenXR, through extensions: eye tracking, certain hand tracking features, spatial anchors and scene meshes among them. Those are the parts of an app most likely to need work when a vendor changes direction.
Engine versions
Unity and Unreal both ship long-term support versions, and staying on one is a reasonable choice for a stable app. The risk is staying too long. Engines and their XR plugins eventually drop support for older devices, older OS versions and older SDKs, and a project that skips several major versions faces one large, risky upgrade instead of several small ones. We cover how the engine decision shapes this in choosing an XR engine.
Store and platform policy
Public stores change their requirements: minimum platform API levels, privacy disclosures, data handling declarations, performance and content rules. Android-based standalone headsets also tend to inherit requirements from the underlying Android platform. A change like this does not break the app that is already installed, but it can block your next update until the project is brought up to date, which is a bad time to learn about it.
Enterprise distribution through device management avoids store review, but not the operating system underneath.
Hardware discontinuation
The headset you standardized on will be replaced. When that happens, you lose easy access to spares and replacements, and the successor model usually has different performance headroom, sensors, controllers and sometimes a different display or field of view. An app tuned carefully for one device will need testing, and often tuning, on the next one.
This matters most when the app depends on a specific hardware capability. Nystag, the VR eye-tracking diagnostics tool we built on the Vive Focus 3, is a good example: in a clinical tool, the eye tracker is not a feature, it is the measurement. Moving to a different headset means more than a recompile. It means checking that the new hardware produces measurements the clinical workflow can still rely on, which is part of what makes clinical VR diagnostics a different kind of project. Hardware longevity is also one of the questions we push on in choosing an XR headset.
The real world, and the data you depend on
Some drift is not technical at all. Procedures change, equipment is replaced and buildings get renovated, and training content has to follow. For a firefighter pre-planning and training platform like ERIS XR, which we built for ARCortex, the value depends on how closely the digital layer matches the physical one.
Apps that consume external data have one more dependency. Planes XR, our location-based AR build for ARCortex, connects to OpenSky to show real flights on live maps, so it relies on an outside service whose availability, limits and format are outside our control. Any app with a live feed needs monitoring and a sensible behavior when that feed is slow or missing, a theme we cover in location-based AR.
Build decisions that make maintenance cheaper
Most of the cost of maintaining an XR app is set during the original build. These are the decisions that pay off most.
Use OpenXR wherever the feature allows it. It is the closest thing XR has to a stable foundation, and it keeps a later move to a new headset from becoming a rewrite.
Put vendor-specific features behind a thin layer of your own. Eye tracking, anchors, passthrough controls and platform services should be called through one module in your code, not scattered across every scene. When a vendor changes an API, you update one place.
Pin the engine and plugin versions, and write the build down. A documented, repeatable build is what lets a different engineer, or a different team, ship an update two years later. If only one person can produce a working build, you do not own the app in any practical sense, which is the core argument of our piece on software ownership and handover.
Automate the build and a basic on-device check. A pipeline that produces a build for each supported headset and runs a short smoke test turns "will this still work?" from a week of manual testing into a routine step.
Separate content from code. If scenarios, text, procedures and 3D assets can be updated without a full app release, the most frequent kind of change stops needing an engineer and a store review. A disciplined 3D content pipeline makes this much easier.
Ship with crash and performance telemetry. After an OS update, the first useful question is whether crash rates or frame times moved on any device. Without telemetry, the only signal is user complaints.
Keep shared sessions version-aware. Multiplayer and co-located experiences, like MR Camera, where several users place and interact with 3D models in the same space, need every device in a session to run compatible versions. Plan for how mismatched clients are detected and handled, because during a staged rollout they will exist. We cover shared sessions further in mixed-reality collaboration.
What a sensible maintenance plan includes
Maintenance does not have to mean a large retainer. For many apps it is a small, predictable set of routines:
- A test window for headset updates. Vendors often make upcoming OS versions available early. Someone should install them on a test device and run the app before your fleet or your users receive them.
- A device lab. One of each supported headset model, kept on the current OS, plus at least one held back on the version your users actually run.
- A regular dependency review. Every few months, check engine, plugin and SDK releases and deprecation notices, and plan small upgrades rather than letting them pile up.
- A yearly hardware review. Is your headset still sold? Are spares available? Which successor would you move to, and what would porting involve?
- Monitoring. Crashes, performance and any external services the app depends on, with someone named to respond.
- A clear agreement on who does what. Whether the work sits with your team, the original studio or someone else, it should be written down before launch, including how fast urgent breakages are handled. The contract model matters here too, and we compare the options in fixed price vs time and materials.
If you are inheriting an XR app that has already drifted, with an old engine version, a deprecated SDK and no documented build, the first step is an assessment rather than a quote for new features. The approach is similar to the one we describe in legacy system modernization: get a reproducible build, find out what still works on current hardware, then upgrade in deliberate steps.
How to budget for it
We will not give a universal percentage, because the honest answer depends on how many headset models you support, how much the app relies on vendor-specific features, whether it is on a public store, whether it uses live data and how often your content changes. A single-device enterprise app with fixed content and device management needs far less attention than a multi-headset store app with shared sessions and eye tracking.
What we can say is that maintenance should appear in the original budget as an ongoing cost, alongside hardware refresh and content updates, and that the build decisions above are the biggest lever on its size. Our guide to what an XR app costs covers the build itself.
Questions to ask before you commission an XR build
- Which parts of the app use vendor-specific features, and how are they isolated?
- Is the app built on OpenXR, and where does it depart from it?
- Which engine version will it ship on, and what is the plan for upgrades?
- How are headset OS updates tested before they reach our users?
- Can content be updated without a full app release?
- What telemetry ships with the app, and who watches it?
- If we had to hand this to another team in two years, what would they receive? The answer should include source, assets, a documented build and the accounts needed to publish.
A partner who treats launch as the end of the job is quoting you the first chapter.
The bottom line
An XR app is only as stable as the stack under it, and that stack belongs mostly to other companies. Headset updates, SDK deprecations, engine upgrades, store policy and hardware turnover will all reach your app eventually. The teams that handle this well do not avoid change. They build so that change lands in one place, test updates before users see them, and plan the cost from the start.
Planning an XR build, or inheriting one that has started to drift? Book a demo and we will walk through the stack, the upgrade risks and a maintenance plan that fits your fleet. See our XR work: ERIS XR and Planes XR for ARCortex, Nystag clinical VR eye-tracking on the Vive Focus 3, and MR Camera shared mixed reality.