How an iOS App Development Company Bridges iOS Apps to visionOS
Adapting SwiftUI Ornaments, 3D Spatial Audio, and Shared Volumetric Scenes Between iPhone and Apple Vision Pro
A team I talked with recently had already built a solid iOS inventory app. Clean data model, real authentication, years of refined business logic behind it. Their first instinct for a visionOS version was to just scale the same screens up and drop them into a window on Vision Pro. It ran. It also felt completely wrong the moment someone put the headset on, because nothing about depth, distance, or where your eyes naturally land had been considered. The screens weren’t spatial. They were just bigger.
That’s the trap most teams fall into early. An iOS app can carry real, valuable business logic, its APIs, its auth flow, its data models, all of it genuinely reusable. None of that automatically becomes a good spatial experience once you’re on Vision Pro. The interaction model itself changes, and pretending otherwise is how you end up with an app that technically runs on visionOS but never feels like it belongs there.
What Can Actually Be Shared?
Start with the layer that travels well. Networking code, data models, authentication, business logic, API services, state management — these can largely move across platforms untouched, assuming they were written with reasonable separation from the UI in the first place. We saw this play out clearly while building a vocal coach app with guided vocal exercises, where the core exercise logic and user progress tracking stayed intact even as the interface layer evolved. If your networking layer is tangled up with UIKit view controllers, that’s a different, harder conversation, but a cleanly separated Swift package of models and services is genuinely portable.
Design tokens, colors, typography scale, spacing values, tend to carry over conceptually even if the visual treatment shifts. UI components are where things get messier. A button that works fine tapped with a thumb on a six-inch screen behaves differently when someone’s looking at it from across a room and pinching to select it. Some SwiftUI views translate cleanly. Plenty need real platform-specific attention, particularly anything built around dense information density or small tap targets designed for a phone in hand.
SwiftUI as the Bridge, Not a Universal Skin
SwiftUI genuinely helps here, but not in the way marketing copy usually implies. It’s not “write once, run everywhere.” It’s closer to “write shared foundations once, then let each platform present them appropriately.” You lean on conditional platform behavior where interaction models diverge, adaptive layouts where screen real estate and viewing distance differ, and platform-specific navigation patterns rather than forcing a single navigation stack to behave identically on iPhone and Vision Pro.
Windows on visionOS aren’t just resized iPhone screens either. They’re floating in space, viewed from a distance that changes depending on where the user positions them, and they need to hold up visually and functionally across that range. Treating a visionOS window as “the iPhone screen but bigger” is exactly the mistake that made the inventory app I mentioned feel off. The content needs breathing room designed for how people actually look at things floating a few feet in front of them.
Ornaments Change the Interface Hierarchy
Ornaments are one of the more underappreciated pieces of visionOS design, and they solve a real problem. On iPhone, controls typically sit inside the same visual frame as your content, a toolbar pinned to the top or bottom of the screen. On visionOS, ornaments let you attach controls just outside the primary window or volume, floating below or beside it rather than competing for space within it.
That matters more than it sounds. Volumes support toolbars that float in an ornament beneath them, and that toolbar automatically scales as the volume gets repositioned, so controls stay reachable no matter where someone drags the content in their space. Picture a productivity app: the main workspace stays inside the window, doing what it’s supposed to do, while frequently used controls sit in an ornament just below it, always within reach but never cluttering the actual content. That’s a genuinely different interface hierarchy than conventional iPhone navigation, not a cosmetic reskin of the same layout.
From Flat Screens to Volumetric Content
visionOS gives you three scene types: windows, volumes, and immersive spaces, and knowing when to reach for each one is most of the design decision. Windows are your familiar flat, 2D SwiftUI content, just presented spatially. Volumes let you showcase real 3D content, viewable from any angle, built with RealityKit. Immersive spaces go further still, letting an app create unbounded 3D environments or fully surround the user.
RealityKit becomes relevant the moment 3D actually serves the task rather than decorating it. A furniture app showing how a couch looks in your actual living room has a legitimate reason to go volumetric. A settings screen does not, no matter how tempting “immersive” sounds in a pitch deck. The test worth applying honestly is whether depth improves comprehension or interaction for that specific screen. If the answer’s no, a flat window is the right call, and there’s no shame in that.
Spatial Audio Is Part of the Interface, Not Background Noise
It’s easy to file spatial audio under “nice extra” rather than treating it as an actual interface element, but that undersells what it does. Directional, object-based audio can communicate information without needing another visual control cluttering the scene. A notification that sounds like it’s coming from slightly behind and to the left tells the user where to look, without a badge or an animation demanding their attention.
Get Charleswade’s stories in your inbox
Join Medium for free to get updates from this writer.
That has real accessibility value too. Someone who’s momentarily looking elsewhere in a large immersive space can still register that something needs attention, purely from where the sound seems to originate. A collaborative app might use spatial audio to indicate which teammate is currently speaking, letting the user’s ear do work their eyes would otherwise have to do. That’s the interface, functioning through sound rather than pixels.
Shared Volumetric Scenes and Memory
This is where teams get into real trouble if they’re not careful. iPhone and Vision Pro have genuinely different hardware profiles and interaction demands, and asset strategy has to account for that rather than assuming one 3D model works everywhere at full fidelity.
Lazy loading matters more here than in most iOS work, since a volumetric scene with high-poly models and large textures loaded eagerly on launch will hurt performance in ways users notice immediately, particularly in a headset where a frame drop feels physically uncomfortable rather than just visually janky. Level of detail systems, where a model swaps to a simpler mesh at distance and a more detailed one up close, are worth building into the asset pipeline early rather than retrofitting later.
Reusable assets, sensible texture sizing, and thinking about resource lifecycle, when a scene loads its content and when it releases it, all become genuinely load-bearing decisions rather than nice-to-haves. When scaling spatial UI components across multi-device Apple ecosystems, partnering with a forward-looking iOS app development company ensures shared volumetric scenes compile cleanly without inflating memory footprints, since this is exactly the kind of cross-device optimization work that gets skipped under deadline pressure and shows up later as stutter nobody can easily diagnose.
RealityKit’s more recent additions, physical space lighting, projective textures, and richer material handling among them, expand what’s visually possible, but none of that changes the underlying discipline required around asset weight and loading strategy.
Architecture for Cross-Device Apple Apps
A workable structure separates cleanly into three layers. A shared layer holds models, networking, authentication, business logic, and services, the stuff that genuinely doesn’t care what platform it’s running on. An iOS layer wraps that shared layer in touch interaction, compact layouts, and conventional iPhone navigation. A visionOS layer wraps the same shared layer in spatial windows, ornaments, volumetric content, immersive experiences where appropriate, and spatial audio.
That separation is more maintainable than duplicating the whole app, obviously, but it also forces a useful discipline. It keeps the shared layer honest, because platform-specific UI code has nowhere to sneak into the business logic if the architecture doesn’t allow it. Teams that skip this separation tend to discover, months in, that their “shared” code was never really shared, just copied and quietly diverging.
When an iOS App Should Become a Spatial App
Not every app benefits from a visionOS version, and that’s worth saying plainly. Before committing real engineering time, it’s worth asking a few honest questions. Does spatial visualization actually improve the task, or would it just look impressive in a demo. Is 3D information genuinely useful here, or is 2D data being forced into three dimensions for no real reason. Does the workflow benefit from a larger spatial workspace than a phone screen allows. Will users be interacting with physical objects or their actual environment in a way that makes spatial computing relevant. Is hands-free interaction genuinely valuable for this use case. Does spatial audio offer meaningful feedback, or would it just be noise. And realistically, is the target audience likely to own or use a Vision Pro at all.
Sometimes the honest answer is that adapting the existing iOS interface, with sensible windowed presentation and maybe an ornament or two, is entirely sufficient. Other times the workflow genuinely calls for a volumetric or immersive redesign. Confusing enthusiasm for spatial computing with an actual product need is how teams end up over-engineering a settings screen into an immersive space nobody asked for.
Testing Across iPhone and Apple Vision Pro
Testing purely against an iPhone simulator tells you almost nothing about how an app will behave on Vision Pro. UI testing needs to account for interaction patterns that don’t exist on iPhone at all — gaze and pinch instead of touch. Teams working across mixed development environments often run into setup friction long before testing even starts, which is why knowing how to build iOS apps on a Windows machine matters for distributed teams juggling both platforms. 3D asset testing needs real device runs to catch performance and memory issues a simulator won’t surface accurately.
Frequently Asked Questions
- Can an existing iOS app run on visionOS?
Many iOS apps can run on visionOS with minimal changes through Apple’s compatibility support, but running is different from being genuinely usable. A good spatial experience usually requires adapting layout, navigation, and interaction rather than relying purely on automatic compatibility. - How much iOS code can be reused for visionOS?
Shared business logic, networking, data models, and authentication typically transfer with little to no change, since these layers don’t depend on how content gets displayed. UI code needs more selective treatment, since interaction and layout genuinely differ between the two platforms. - Can SwiftUI be shared between iOS and visionOS?
Yes, SwiftUI works across both platforms and is the most practical way to share foundational UI code, but shared code doesn’t mean an identical interface. Platform-specific adaptation, particularly around windows, ornaments, and spatial presentation, still needs deliberate design work. - What is the difference between a visionOS window and a volumetric scene?
A window presents flat, 2D SwiftUI content positioned in space, similar in structure to a traditional app screen. A volume showcases real 3D content built with RealityKit, viewable from any angle, and is meant for content that genuinely benefits from spatial depth. - How does spatial audio work in visionOS apps?
Spatial audio uses directional, object-based sound so audio appears to originate from a specific point in the user’s environment, which can communicate location, attention cues, or feedback without adding visual clutter to the interface. - When should an iOS app be redesigned for Apple Vision Pro?
When the task genuinely benefits from spatial visualization, a larger workspace, hands-free interaction, or interaction with physical objects and environments. If none of those apply, adapting the existing interface into a well-designed window is usually the more sensible path. - What frameworks are used for visionOS development?
SwiftUI handles interface and scene structure, RealityKit handles 3D content and volumetric scenes, and ARKit supports spatial understanding and environment awareness, with all three typically working together rather than being used in isolation.
