Holographic Interfaces: SDKs and Patterns for [2026]

As of May 11, 2026, building a "holographic interface" is less about one universal display standard and more about shipping across three concrete stacks: visionOS, Android XR, and light-field WebXR targets like Looking Glass. The portable strategy is to treat immersion as a capability, not a default. Build a bounded spatial shell first, then promote to full-space or light-field rendering only when the hardware and user task justify it.

• Windows, panels, and volumes are the safest first target for production XR UI.
• Immersive spaces should be entered intentionally, not at launch by default.
• Android XR keeps apps in Home Space unless you request Full Space.
• Looking Glass adds desktop holographic output through a WebXR polyfill and Bridge.

Prerequisites and architecture

The design pattern behind that advice is simple:

• Task UI lives in a bounded surface so people can read, drag, resize, and dismiss it predictably.
• 3D objects live in bounded containers such as a volume or panel-adjacent scene, unless the content truly needs room-scale placement.
• Immersive mode is a state change, not your app's identity.
• Display adapters stay thin; business logic and scene state should not care whether the output is visionOS, Android XR, or a light-field display.

1. Start with a bounded spatial shell

Apple's visionOS guidance is explicit: start with a familiar window-based experience, then add volumes or spaces where they add value. Apple's Human Interface Guidelines also distinguish windows for familiar interfaces from volumes for rich 3D content. Android XR points in the same direction: apps launch in Home Space by default, and spatialization is only available in Full Space. That means your first shipping milestone should be a bounded shell, not a room-filling world.

visionOS: window for workflow, volume for inspection

@main
struct HoloApp: App {
    @State private var immersion: ImmersionStyle = .mixed

    var body: some Scene {
        WindowGroup {
            DashboardView()
        }

        WindowGroup(id: "model") {
            Model3D("device")
        }
        .windowStyle(.volumetric)
        .defaultSize(width: 0.8, height: 0.8, depth: 0.4, in: .meters)

        ImmersiveSpace(id: "inspection") {
            RealityView { content in
                let marker = ModelEntity(mesh: .generateSphere(radius: 0.05))
                content.add(marker)
            }
        }
        .immersionStyle(selection: $immersion, in: .mixed, .full)
    }
}

This structure does three useful things. It keeps your default workflow in a standard WindowGroup, puts inspectable 3D content inside a volumetric window with a physical size in meters, and reserves ImmersiveSpace for a later user action.

Android XR: panel as the default shell

dependencies {
    implementation("androidx.xr.scenecore:scenecore:1.0.0-alpha14")
}

@Composable
fun SpatialShell() {
    Subspace {
        SpatialPanel(
            SubspaceModifier
                .width(1400.dp)
                .height(824.dp),
            dragPolicy = MovePolicy(),
            resizePolicy = ResizePolicy(),
        ) {
            DashboardPanel()
        }
    }
}

Jetpack Compose for XR exposes SpatialPanel as the core bounded surface. Keep dense controls, search, metadata, and navigation there. Then place 3D previews next to the panel instead of replacing the panel outright.

• Use a window or panel for forms, lists, code views, and dashboards.
• Use a volume when the object itself is the feature, such as product inspection or CAD review.
• Use attachments for 2D labels pinned to 3D content instead of floating HUD layers.

2. Promote to immersive mode on demand

Once the shell exists, add a deliberate transition into immersion. On visionOS, the system allows only one immersive space at a time. On Android XR, you explicitly request Full Space. In both ecosystems, immersion is operationally a mode change, which means your app state, navigation, and exit path need to be explicit.

visionOS: open the space asynchronously

struct MainView: View {
    @Environment(\.openImmersiveSpace) private var openImmersiveSpace

    var body: some View {
        Button("Inspect in space") {
            Task {
                let result = await openImmersiveSpace(id: "inspection")
                if case .error = result {
                    print("Unable to open immersive space")
                }
            }
        }
    }
}

Android XR: request Full Space only when the task needs it

@Composable
fun EnterFullSpaceButton() {
    val session = LocalSession.current ?: return

    Button(onClick = { session.scene.requestFullSpaceMode() }) {
        Text("Enter Full Space")
    }
}

Design-wise, this is where many teams overbuild. Don't move the whole product into immersion just because the headset supports it. Reserve immersive mode for tasks that gain something specific from surrounding context:

• Room-scale comparison of large models or environments.
• Spatial training where distance and placement affect understanding.
• Guided walkthroughs that need the user's surroundings or a fully controlled environment.

3. Add light-field output for desktop holographic displays

For desktop holographic displays, the cleanest currently documented route is Looking Glass WebXR. The official docs state that the library requires Looking Glass Bridge, works in Chromium-based browsers and Firefox, recommends Chrome-based browsers for best performance, and does not support Safari.

npm install @lookingglass/webxr

import { LookingGlassWebXRPolyfill, LookingGlassConfig } from "@lookingglass/webxr"

const config = LookingGlassConfig
config.targetY = 0
config.targetZ = 0
config.targetDiam = 3
config.fovy = (40 * Math.PI) / 180

new LookingGlassWebXRPolyfill()

That adapter layer is powerful because it lets you keep the scene graph and interaction model mostly engine-agnostic. The key design adjustments for light-field output are visual, not architectural:

• Reduce stacked HUD chrome; layered 2D overlays feel flatter than anchored labels.
• Use conservative depth; large depth swings look impressive in demos but hurt readability.
• Prefer a central object stage over wide, room-scale layouts because the display is still a fixed desktop surface.
• Test the pop-up workflow; users must move the XR window onto the Looking Glass display and activate it there.

Verification and expected output

At this point, you should be able to verify the architecture without building a giant demo app.

1. visionOS shell check: the main window opens first, and the 3D model opens in a volumetric window with fixed physical sizing.
2. visionOS immersion check: tapping the action button opens the ImmersiveSpace; trying to open another one without dismissing the first should return an error path.
3. Android XR mode check: your app remains usable in Home Space, then transitions into Full Space only when requested; the panel stays draggable and resizable.
4. Looking Glass check: the WebXR view opens in a separate window, moves to the holographic display, and shows stable parallax after activation.

If all four checks pass, you have the right foundation: one app model, multiple spatial presentations, and a thin holographic output adapter.

Troubleshooting and what's next

Top 3 fixes

1. The interface feels overwhelming in 3D. Move dense controls back into a window or panel, and keep only object-local controls attached to the 3D content.
2. Android spatial UI never appears. Confirm that you're actually entering Full Space; Android's docs are clear that spatialization is supported only there.
3. Looking Glass output opens incorrectly or looks flat. Make sure Looking Glass Bridge is installed, use a supported browser, avoid Safari, and retune targetDiam and fovy on the physical display.

What's next

• Add a shared scene-state layer so your app can swap between panel, volume, immersive, and light-field presenters.
• Introduce anchored 2D labels with RealityView attachments on visionOS instead of floating text planes.
• Split Android XR features behind capability checks so Home Space remains useful even without spatial UI.
• Build a small visual test matrix: simulator, headset, browser preview, and physical light-field display.

The main 2026 lesson is pragmatic: holographic interfaces are now a packaging problem more than a rendering novelty. If you standardize on bounded spatial shells and explicit immersion transitions, the SDK differences become manageable instead of architectural.