TL;DR: Building for Apple Vision Pro is less like building a VR game and more like building an Apple app that happens to live in space. visionOS apps are made from windows, volumes and immersive spaces, built natively with SwiftUI and RealityKit or cross-platform with Unity, and they run under strict privacy rules: no raw gaze data, no camera feed for ordinary apps, and room and hand data only once the app takes over the user's space. Decide early whether you need a native Apple experience or one app across several headsets, check that the data your idea depends on is actually available, and plan distribution and device management before the first line of code.
Vision Pro gets asked about in almost every XR conversation we have. Sometimes it is the right device. Often the question behind it is really "should our immersive project be on the premium headset?", and the answer depends on things that are easy to miss in a demo: what the platform lets an app see, how users interact with it, how the app gets onto devices and whether the rest of your fleet is Apple at all.
This guide covers what is different about building for visionOS, the decisions that shape scope and cost, and when another headset is the better fit. For the wider hardware comparison, start with our guide to choosing an XR headset.
How visionOS apps are structured
Most VR platforms assume an app takes over the whole view. visionOS does not. Its building blocks are:
- Windows: flat, resizable SwiftUI panels floating in the user's room. Many business apps start, and sometimes stay, here.
- Volumes: bounded 3D containers that hold a model or scene the user can walk around, sitting alongside other apps.
- Immersive spaces: the app takes over the space around the user, either blending content into the room (mixed), partly replacing it, or fully replacing it with a virtual environment.
By default, apps share the space with other apps, the way windows share a desktop. An app has to open an immersive space to take over, and that switch matters more than it looks, because several capabilities only become available there.
The practical consequence for scoping is that "a Vision Pro app" can mean anything from an existing iPad app running in a window to a fully immersive simulation. Those are very different projects. A product dashboard with one 3D volume for inspecting a model is a modest build. A full immersive training scenario is closer to a game.
What the platform lets your app see
This is where many ideas need adjusting, and it is better to find out in week one than in week six.
Eye tracking drives the interface, not your data
Vision Pro's main input is looking at something and pinching. The system tracks the user's eyes precisely, but it does not hand that gaze data to apps. Hover highlights are drawn by the system, and your app learns only what the user selected. That is a deliberate privacy choice, and it rules out ideas that depend on reading where someone looks, such as attention analytics or gaze-based assessment.
This is a real example of the headset following the data, not the other way round. Nystag, the clinical VR eye-tracking diagnostics tool we built, runs on the Vive Focus 3, where the eye tracker is available to the app and is the measurement itself. We cover why that matters in clinical VR diagnostics.
Camera, room and hands
Ordinary visionOS apps do not get the passthrough camera feed. Apple has added enterprise APIs that can grant main camera access and some other capabilities to in-house business apps, but they require a specific entitlement and an enterprise arrangement with Apple, and they are not available to apps on the public App Store. If your concept involves recognizing objects or reading labels through the headset, confirm which route you are on before you commit.
Room understanding (planes, a mesh of the surroundings, anchors) and detailed hand tracking are available through ARKit, but only while the app has an immersive space open and the user has granted permission. An app that wants to snap content to a real table or let users grab objects by hand therefore has to be designed around an immersive mode. Our piece on XR data and privacy covers how to handle this kind of sensor data responsibly on any platform.
Native or Unity: the first big decision
There are two main routes, and the choice ties back to everything else in the project.
Native: SwiftUI, RealityKit and Reality Composer Pro
Apple's own stack gives the most natural visionOS experience. Windows, system materials, gestures, accessibility features, SharePlay and other Apple frameworks all come built in, and the app feels like it belongs on the device. It is the strongest route for apps that are mostly interface plus some 3D, and for organizations that already ship iPhone and iPad apps, because a lot of Swift code and design work can be shared.
The trade-off is that a native visionOS app runs on Apple devices only. If you also need Quest, Pico or Vive headsets, you are building a second app.
Unity
Unity supports visionOS, both for fully immersive apps and, through its PolySpatial technology, for content that sits in the shared space alongside other apps. It makes sense when the same experience needs to run on several headsets, or when the project is a heavily 3D, game-like simulation where Unity's tooling and existing assets pay off.
The trade-off is that Unity apps on visionOS have constraints of their own, particularly in shared-space mode, where rendering goes through Apple's system rather than Unity's own pipeline. Expect to test effects and shaders on the device early. We go deeper on the engine decision in choosing an XR engine, and the same reasoning that applies to phones in native vs cross-platform app development applies here.
A third route is worth knowing about: Safari on visionOS supports WebXR for immersive sessions, which can suit lightweight demos and marketing experiences that should not require an install. The limits of browser-based XR are covered in WebAR without an app.
Designing for look-and-pinch
Interaction design on Vision Pro is closer to good iPad design than to controller-based VR. Targets need enough size and spacing to be selected comfortably with the eyes, content should sit at a comfortable distance and height, and most interactions should work with hands resting in the lap. Users can reach out and touch content directly, but designing an entire app around raised arms is tiring.
Immersion should be the user's choice, introduced gradually. Starting in a window and offering an immersive mode tends to work better than dropping someone into a full environment the moment the app opens, and it keeps the motion comfort principles from our VR motion sickness guide easier to follow. General patterns are in XR interaction design, and visionOS's built-in accessibility features (VoiceOver, alternative pointer inputs, zoom) carry over to native apps more or less for free, which is a head start on the work described in XR accessibility.
Shared and multi-user experiences
Apple offers SharePlay for shared sessions, and visionOS supports spatial Personas so remote participants can appear in the space. For people in the same room, recent visionOS versions add support for sharing an experience between nearby Vision Pro users.
These are strong building blocks if everyone involved is on Apple hardware. If a session has to mix Vision Pro with other headsets, you are back to a custom networking layer, which is the approach we took on MR Camera, a multiplayer mixed-reality environment where several users place and interact with 3D models in the same space. The trade-offs are in mixed-reality collaboration.
Distribution and device management
For consumer and public apps, distribution is the visionOS App Store with Apple's usual review. For business use, Vision Pro can be enrolled in a mobile device management system and apps can be deployed privately, which is how most enterprise pilots should run. Plan the device setup, shared-device sign-in and how headsets are cleaned and charged between users, because those details decide whether a pilot survives contact with a real team. Our guide to enterprise XR rollout covers this side in full.
Like any headset platform, visionOS changes every year, and new versions regularly add and adjust APIs. Budget for keeping up, as described in XR app maintenance.
When Vision Pro is the right choice, and when it is not
Vision Pro tends to fit when:
- Display quality is the point, such as reviewing detailed designs, products or medical imaging at true scale.
- The audience is small and high value, like executives, sales demos, clinicians or design reviewers, where device cost per user matters less.
- Your organization is already on Apple, with iPhone and iPad apps, Apple device management and Swift skills in house.
- The experience is mostly interface plus 3D, which visionOS handles very well.
Another headset is usually a better fit when:
- You need a fleet, such as dozens of devices for training, where cost per seat and ruggedness dominate. That is typical for programs like the ones in VR training for high-risk teams.
- You need data visionOS keeps private, like raw gaze or the camera feed without an enterprise arrangement.
- You need controllers or full freedom of movement for physical, simulation-heavy tasks.
- You need one app across many headsets and do not want to maintain an Apple-only variant.
Plenty of good XR work never touches Vision Pro. ERIS XR, the firefighter pre-planning and training platform we built for ARCortex, and Planes XR, its location-based AR experience showing real flights from OpenSky on live maps, are both judged on whether they work for their users in their setting, not on which headset is most impressive.
What drives the cost
We will not quote a typical number, because the range is too wide to be useful. The main drivers are:
- App type: windows only, windows plus volumes, or full immersive spaces.
- Route: native only, Unity only, or both because Vision Pro is one of several targets.
- 3D content: how many models, how detailed and whether they already exist. See our 3D content pipeline guide.
- Platform capabilities: room mapping, hand tracking, shared sessions or enterprise APIs.
- Integrations and distribution: logins, backends, device management and App Store review.
The broader picture is in what an XR app costs.
Questions to answer before you start
- Does our idea need any data visionOS does not give apps, such as gaze or the camera feed?
- Is this a window, a volume or an immersive experience, and which one is the minimum useful version?
- Is Vision Pro our only target, or one of several headsets?
- Who are the users, and how many devices will we realistically buy?
- Will the app go on the App Store or be deployed privately through device management?
- Who maintains it when the next visionOS version ships?
Weighing Vision Pro against other headsets for an immersive project? Book a demo and we will look at your idea, the data it depends on and the platform that fits it best. 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.