Augmented reality and virtual reality get lumped together constantly, and they shouldn’t be. They create very different experiences, need different hardware, and suit different projects. If you’re considering an immersive project — a game, a training tool, a product experience — getting the AR-versus-VR choice right at the start saves you from building the wrong thing well. Here’s the practical difference and how to choose.
The Core Difference: Replace vs Augment
Virtual reality replaces the real world entirely. With a headset on, the user is somewhere else — fully immersed in a digital environment, present in a place that isn’t there. Augmented reality keeps the real world and adds to it — digital objects and information overlaid on what the user actually sees, through a phone or AR glasses. One transports you; the other enhances where you already are. That single distinction drives almost every other decision.
Where VR Shines
VR wins when total immersion is the point: deeply immersive games, training simulations where practicing in a safe virtual environment is genuinely valuable, virtual walkthroughs of places that don’t exist yet, and experiences where you want the user’s full attention with no distractions. The trade-off is that VR requires a headset and a dedicated space, which naturally limits reach — it’s a considered experience, not a casual one.
Where AR Shines
AR wins when the value is in connecting digital content to the real world, and when reach matters. Because it runs on the phone in nearly everyone’s pocket, AR reaches an audience VR can’t: previewing furniture in your actual room, overlaying instructions on real equipment, location-based games, interactive marketing. The immersion is lighter, but the accessibility is enormous — no special hardware, just an app.
Choosing Between Them
- Does the experience need the real world? If real-world context is the point → AR. If you want to leave it behind entirely → VR.
- How many people must reach it easily? Broad, casual reach → AR on phones. A committed, focused audience → VR is acceptable.
- How deep must the immersion be? Total presence → VR. Useful enhancement → AR.
Answer those honestly and the choice usually makes itself. The mistake is picking the technology first — “we want to do VR” — and then forcing a project onto it that would have been better, and reached more people, as AR.
SoftwareSplash builds both AR and VR experiences — and we’ll help you choose the one that fits your goal, audience, and budget rather than the one that sounds most futuristic. Tell us what you want to create and we’ll point you to the right technology.
Passthrough Moves the Line Inside the Build, Not Off the Table
On a passthrough-capable headset, the AR and VR distinction moves inside a single build. The same device renders a fully virtual scene in one moment and composites virtual objects over a live camera view of the room in the next, so on that hardware the AR-or-VR call becomes a per-scene design decision rather than a fixed property of the product. The choice above still has to be made on day one at the level of form factor: headset or handheld. A phone experience and a headset experience differ in input model, session length, where the user physically is when they run it, and how it gets distributed, and no runtime toggle reconciles those.
The two ways a headset shows you the room behave differently. Video passthrough routes the outward-facing cameras to the displays, so virtual content is composited over a camera image and can be fully opaque, hiding the camera image behind it and holding its own color. The cost is that the entire real world now arrives through the camera pipeline: limited resolution and dynamic range, noise and motion blur when the room is dim, color shifts, and added latency on everything you see, including your own hands. Optical see-through, the waveguide approach used by glasses-form devices, adds light to the real scene and cannot subtract it. Black renders as transparent, dark or low-contrast content washes out in a bright room, virtual objects read as made of light rather than matter, and the drawable field of view is a window inside your natural field of view rather than the whole of it.
The test that separates them is whether your content has to look solid. Anatomy, machinery, a vehicle interior, anything the user is meant to read as a real object, needs opacity and therefore video passthrough or full VR. Labels, arrows, callouts, alignment guides and numbers work as light and survive optical see-through fine. Handheld AR is a third case rather than a cheaper version of either: the display is not on the user's eyes, so the experience is a window they aim, usually one-handed, at arm's length, with the scene registered to the camera pose instead of the head pose. Content designed to be walked around inside a headset rarely survives the move to a device the user is holding up.
The Frame Budget Is the Real Constraint, and It Differs by Route
Almost every technical decision on an immersive project sits downstream of a fixed per-frame time budget, and that budget is smaller than teams expect. A headset running at 90 Hz gives you about 11 milliseconds per frame, 72 Hz gives about 13.9, and 120 Hz gives about 8.3. That budget covers both eyes. Stereo does not cost exactly double, since culling, shadow maps, physics and simulation are shared and single-pass instanced rendering cuts the draw call overhead, but everything view-dependent runs twice.
Missing that budget in VR is not a quality problem, it is a comfort problem. Compositor reprojection can synthesize an intermediate frame from updated head rotation and hide part of a miss, but it corrects rotation far better than translation, so dropped frames surface as smearing on near objects and judder on anything moving in the scene. The underlying discomfort mechanism is vestibular mismatch: the eyes report motion the inner ear does not confirm. That is why frame timing, latency spikes, software-applied yaw, and acceleration the user did not initiate all produce the same symptom, and why the mitigations are design decisions rather than settings. Teleport or snap turning instead of smooth locomotion, a vignette during translation, a static reference frame such as a cockpit or vehicle body kept in view, constant velocity in preference to acceleration, and head tracking that is never taken away from the user.
Handheld AR renders one view instead of two, which sounds easier and is not. The tracking stack the experience depends on runs continuously alongside it: camera capture every frame, visual-inertial odometry fusing camera features with the IMU, plane detection, and on capable devices depth estimation and scene meshing. All of it competes with your rendering for GPU time, memory bandwidth and power on a passively cooled device. The practical result is sustained thermal throttling. A scene that holds frame rate for the first minute can be running measurably slower several minutes into a session with the camera active and the screen at full brightness, which is exactly the outdoor case. Battery drain follows the same curve, so session length is a design constraint, not an afterthought.
What Ports Between Them, What Does Not, and What You Are Hiring For
If there is any chance of doing both, know in advance what survives the crossing. Simulation logic, assessment and scoring rules, backend services, session records and content data port cleanly. Source art ports with rework rather than as-is: materials get rebuilt for the target's shading and lighting path, level-of-detail chains and polygon budgets get rebuilt for standalone mobile-class silicon, and texture memory has to fit a much smaller ceiling than a desktop build assumed.
The interaction layer does not port, and it is usually the larger share of the work. Six-degree-of-freedom controllers and tracked hands, world-space UI you reach out and touch, room-scale movement and two-handed manipulation have no equivalent on a screen that is simultaneously the viewport and the only input surface. Going the other way, a touch experience built around tap, pinch and drag on a device the user aims does not become a headset experience by being rendered in stereo. Budget for rebuilding that layer instead of discovering it mid-project.
The API surfaces differ too. Headset targets go through OpenXR for core tracking, input and rendering, but the features that make an experience specific, passthrough composition, spatial anchors, scene understanding, hand and eye tracking, still arrive through vendor extensions with uneven availability per device. Handheld AR goes through ARKit on iOS and ARCore on Android, normally behind an abstraction layer that presents one API to your code. That abstraction hides the syntax difference, not the capability difference: plane detection, depth, meshing, image and object tracking are not equally available or equally accurate on both, and a feature your design leans on may exist on one platform and be absent or approximate on the other.
Structure accordingly. What holds up is a shared core with two genuinely separate front ends, not one build with a device toggle threaded through it. On hiring, the scarce skill is not the engine on the resume. It is having shipped inside a fixed frame budget on constrained hardware and having profiled to find out why a frame went over rather than guessing. A team that has only built for desktop or ordinary mobile will meet that discipline for the first time on your project, and the learning happens on your schedule.
Where the Obvious Answer Is Wrong
Reflex one: training means VR. The dividing question is where the training value actually lives. If it lives in the consequence, the failure you cannot safely stage, the rare event, the environment that is expensive or dangerous to enter, then a fully virtual environment is the only place to rehearse it. If it lives in a procedure carried out on a specific physical unit the trainee is standing in front of anyway, overlaying the sequence on the real machine keeps the physical feedback, weight, resistance, the feel of a fastener seating, that a virtual version has to approximate. The follow-up question is whether the technician's hands are occupied, which is a headset-versus-handheld decision rather than an AR-versus-VR one.
Reflex two: reach. The reach test above routes broad, casual audiences to AR on phones, and that routing holds. The follow-up question is what reach means once you are on that route, because addressable devices and completed sessions are different numbers. Between them sit an install or load step, a camera permission prompt, and a physical environment that has to give the tracker something to lock onto. Plan the funnel rather than measuring it after launch, and give the same content a non-AR path, a plain interactive 3D view or a short video, for everyone who declines the camera, is somewhere unsuitable, or does not want to hold a phone up in public. That is not a different routing decision. It is the fallback the AR route needs in order to deliver the reach it was chosen for.
Reflex three: fidelity. When an early build does not feel present, the instinct is to raise visual quality. Presence responds far more to tracking stability, low and consistent latency, correct one-to-one scale, and interaction that answers immediately than to texture resolution or polygon count. A plain scene at the right scale where objects react the moment you touch them reads as more real than a detailed one that stutters, or one in which a doorway is subtly the wrong height. Fidelity work that costs frame time usually makes presence worse, not better.
Piloting the Decision Cheaply Before You Commit
The thing worth testing is not which acronym you prefer. It is whether the core interaction survives the constraints of the medium, and that can be answered at small scale before the expensive commitments are made.
Build the loop flat first. Whatever the user is meant to do, make it playable on a desktop or phone screen with conventional input before any headset work starts. If the task is not interesting or instructive flat, immersion does not rescue it, and you have learned that for a fraction of the cost. A flat prototype also produces the shared core described above as a byproduct, because it forces the logic to exist independently of any device.
Then pilot against the real constraint. For VR that means iterating tethered to a PC while the design is still moving, since the build and deploy cycle is fast, and porting to the standalone target early enough that the performance shock becomes a design input rather than a launch problem. For AR it means testing on the actual target device class, in the actual rooms, from the start. Tracking behavior cannot be simulated in an editor. Fluorescent flicker, direct sun, glossy floors and blank white walls are the environments that fail, and blank untextured surfaces are the classic silent failure because nothing errors out, the content simply drifts.
Before anyone authors production content, build a deliberately hostile stress scene at the worst case you expect: the highest object and light count, the longest sight line, the most expensive material and transparency setup, the busiest physics or particle moment. Run it on the actual target hardware long enough for the device to reach a steady thermal state, not for sixty seconds, and watch frame time rather than average frame rate, along with dropped and reprojected frame counts and the split between CPU and GPU time. What comes back is a real millisecond budget you can convert into limits for artists, polygon counts, draw calls, texture memory and overdraw, before a single production asset exists. Backing into those limits after the content is built is the expensive version of the same exercise.
Frequently Asked Questions
Why do virtual objects still fail to hide behind real furniture, even on a passthrough headset?
Because compositing over a camera image is not the same as knowing the shape of the room. For a virtual chair to be partly hidden by a real table, the system needs a per-pixel depth estimate of the real scene written into the depth buffer, or a mesh of the room rendered as an invisible occluder. Devices get that depth either from a dedicated sensor or from depth inferred from the cameras, and both are coarser and later than the color image: low resolution relative to the display, soft or bleeding edges, unreliable returns on glass, mirrors, dark and glossy surfaces, and trouble with thin geometry. Hands are hard enough that they usually get a dedicated segmentation path rather than relying on general scene depth. The design consequence is to avoid content that must sit precisely behind real geometry or pass through a real doorway, and to keep virtual objects in open space in front of the user where an occlusion error is not the point of the moment.
If we build a shared core with separate AR and VR front ends, how do we stop them drifting apart?
Make the boundary an intent interface rather than an input one. The core should receive statements like "the user selected component 3" or "the user attempted step 4 out of order," never controller button events or touch coordinates, so it never learns what a controller is and cannot grow device-specific branches. Give the core a headless mode that runs a full session with scripted input and no renderer, then run it in continuous integration so both front ends are validated against identical behavior. Where a front end needs to know what the hardware can do, expose a capability query instead of scattering platform conditionals through core code. The fastest source of drift is not code, it is content: if each front end carries its own copy of scenario definitions, scoring thresholds or localized text, they diverge quietly and nobody notices until the two versions grade the same trainee differently. Keep one authoritative data set that both load.
Does the engine choice change the AR versus VR decision?
Less than teams expect, but not to zero. Unity carries the broadest handheld AR path, with AR Foundation sitting over ARKit and ARCore, and reaches headsets through OpenXR. Unreal covers headsets well and defaults to a high-fidelity rendering path that has to be deliberately scaled back for standalone mobile-class hardware. Godot supports OpenXR for headsets, with handheld AR handled through extensions rather than one first-party abstraction. For the AR half specifically, the useful question about any engine is how current its platform layer is against the latest ARKit and ARCore releases, because that lag decides whether a new depth, anchor or tracking feature is available to you at all or has to wait for the plugin to catch up.
Does phone AR require installing an app?
Not always, and the delivery route affects the funnel more than the content does. On Android, WebXR in Chrome can start an AR session straight from a link. On iOS, Safari does not expose the WebXR AR session, so browser-delivered AR usually falls back to AR Quick Look with a USDZ file, which places a model in the room and supports limited interaction but is not a general runtime. App Clips on iOS and Instant Apps on Android sit in between, delivering a small on-demand slice of a native app without a store install. Web delivery removes the install step and the review cycle, at the cost of tighter memory and asset budgets, download size becoming your load screen, and no access to features only the native SDKs expose. If the experience needs persistent anchors, scene meshing or heavy content, native is the honest answer.
What does each option cost to support after launch?
Different burdens, and neither is zero. A VR deployment is a hardware fleet: charging and storage, firmware and OS updates that can change behavior between versions, device enrollment and managed or kiosk modes for anything that is not a consumer release, play space setup at every location, facepad hygiene on shared units, and a physical area that has to stay clear. A handheld AR deployment is a store presence: a review cycle on every update, OS releases that can change tracking behavior or deprecate an API you rely on, a minimum-spec floor that moves as older devices fall out of support, and a wide device matrix in which camera and sensor quality vary considerably. VR gives you hardware logistics and a short, known device list. AR gives you no hardware logistics and a device list you do not control.
Where does AR tracking actually break, and what should the app do about it?
Low light is the underrated failure. As a room dims, the camera raises gain and lengthens exposure, so the frames feeding the tracker get noisy and motion blurred, feature matching degrades, and drift climbs well before anything visibly breaks. Outdoors, the other failure is placement: GPS is accurate to meters, far too coarse to put a virtual object on a specific bench or storefront, so location-anchored content needs a visual positioning service that matches the live camera image against a prebuilt map of the place, which only works where the location has been mapped and has not changed much since. Whatever the cause, design an explicit tracking-loss state instead of letting content slide. Freeze or hide the objects, say what happened, and offer a re-scan action. Silent drift makes users believe the content itself is wrong; a clear prompt makes it a recoverable moment.