01Delivered
A native visionOS app
An app built with the visionOS SDK, published on the App Store for Apple Vision Pro under your developer account.
Service · Immersive
visionOS Development Services
Commission a spatial app for Apple Vision Pro, built natively for visionOS with SwiftUI, RealityKit and Reality Composer Pro. We decide which parts belong in windows, volumes or a full immersive space, design for gaze and pinch, and take the app through App Store review.
SwiftUI and RealityKit, native
Windows, volumes and spaces planned
Eye and hand input designed in
Deliverables
What a visionOS development engagement delivers.
02Delivered
Scene structure
A clear arrangement of windows, volumes and an optional immersive space, each with defined open and dismiss behaviour.
03Delivered
RealityKit content
3D scenes assembled in Reality Composer Pro with materials, lighting and spatial audio, loaded efficiently at runtime.
04Delivered
Accessible spatial input
Interactions driven by look-and-pinch, direct touch and system gestures, with hover effects and support for visionOS accessibility features.
05Delivered
Shared code with iPhone and iPad
Where you have an existing iOS app, shared Swift packages for models and networking so the spatial app does not duplicate them.
Early decisions
Technical decisions we settle early in visionOS development.
01Decided
Compatible iPad app or native build
An iPad app can run on Vision Pro unchanged; we decide whether that is enough or a native visionOS target is justified.
02Decided
Shared space or full space
Most apps should live alongside others in the Shared Space; we agree when, if ever, the app takes over with a Full Space.
03Decided
Immersion level
Mixed, progressive or full immersion each suit different moments, and the choice affects comfort and how users exit.
04Decided
Content pipeline
Which assets come from existing 3D tools, how they are converted to USD, and how Reality Composer Pro scenes are versioned.
05Decided
Privacy-respecting interaction
Apps do not receive raw gaze data, so we design hover and selection around the system’s privacy model from the outset.
Engagement
How a visionOS development engagement runs.
- 01Phase 1
Spatial concept review
We work out what the product gains from depth and space, and which features stay as flat windows.
- 02Phase 2
Simulator and device prototyping
Early layouts are tried in the visionOS simulator, then on hardware to judge scale, distance and comfort.
- 03Phase 3
Scene and interaction build
Windows, volumes and immersive content are built in parallel with SwiftUI views and RealityKit entities.
- 04Phase 4
Review and release
We prepare spatial screenshots and previews, submit to App Review and support the launch on the visionOS App Store.
Fit
When a visionOS app is the right choice.
01Good fit
Content that benefits from depth
Product configurators, anatomy, engineering models or data that is easier to understand when seen in three dimensions.
02Good fit
Extending an Apple-centred product
Companies with an established iPhone or iPad app that want a spatial version sharing the same Swift foundations.
03Good fit
Focused or premium experiences
Entertainment, design review or collaboration where an immersive moment adds clear value for a high-end audience.
Alternatives
When we recommend something other than a visionOS app.
01Consider
Broad headset reach
If the goal is many users on lower-cost headsets, a Meta Quest or OpenXR app reaches a larger installed base.
Open register02Consider
Phones and tablets first
Handheld AR on iPhone and Android reaches far more people today, and can share assets with a later spatial version.
Open register03Consider
A flat iOS app is enough
If depth adds little, a well-made iPad app runs on Vision Pro in compatibility mode with no separate build.
Open registerWindows, volumes and spaces
visionOS gives apps three building blocks. Windows hold familiar SwiftUI interfaces. Volumes hold bounded 3D content that users can walk around. Immersive spaces take over more of the view for focused experiences.
Good visionOS apps use them sparingly. We begin by deciding which content truly needs depth, keeping the rest in windows where users already know how to work.
Designing for eyes and hands
People select by looking at an element and pinching their fingers. Targets need enough size and spacing for gaze to land reliably, and feedback comes through system hover effects. Direct touch works for content within reach. We design both paths and test them with people unfamiliar with the device.
Comfort in the Shared Space
By default your app sits alongside others in the user’s room. Respecting that space means sensible window sizes, no sudden movement of content and clear exits from immersion. Full Space is reserved for moments that justify it.
Reusing what you have on iOS
Swift packages for data, networking and business logic can be shared between an iPhone app and its visionOS sibling. That keeps the spatial build focused on what is new, rather than reimplementing accounts and sync.
FAQ
Questions to resolve before the build.
01Do we need an Apple Vision Pro to build the app?
Development starts in the visionOS simulator in Xcode, but testing on real hardware is essential for judging scale, comfort and input. We test on devices before release.
02Will our iPad app run on Vision Pro already?
Most iPad apps can run as compatible apps in a window. A native visionOS build adds depth, volumes, immersive spaces and native look-and-feel.
03Can apps track where users look?
No. visionOS keeps gaze private and only tells the app when something is selected. Hover highlights are rendered by the system, which we account for in the design.
04Can you reuse our 3D models?
Usually. Models are converted to USD formats, optimised for real-time rendering and arranged in Reality Composer Pro with materials suited to visionOS lighting.
Related services
Services that pair with visionOS development.
01Pairs with
Cross-engine 3D work
For game-like spatial apps that also target other headsets, Unity’s visionOS support can share one project.
Open register02Pairs with
Spatial interface design
Layout, typography and interaction design suited to windows floating in a room rather than a screen in the hand.
Open register03Pairs with
Browser-based 3D
A WebGL viewer gives the same models an audience outside the headset, useful for sharing and marketing.
Open registerPrimary sources
References behind this page
Dated official documentation, standards, and research that support the factual claims on this page.
- 01Apple Developer: visionOS
Apple’s hub for building spatial apps with SwiftUI, RealityKit and ARKit on Vision Pro.
- 02Apple Developer Documentation: visionOS
Reference documentation for windows, volumes, immersive spaces and spatial input.
How to read this page
Scope, cost and timeline figures are planning guidance until confirmed in a written proposal. Diagrams and screens are illustrations, not client deliverables, and source-code rights and handover follow the signed agreement. See the delivery process and the full disclaimer.
Next decision
Turn the brief into an accepted product scope.
Define outcomes, constraints, evidence, rights and handover before delivery begins.
Commercial rights, repositories, environments, documentation, acceptance and handover remain contract-defined.