SpacePlanner persistence, collaboration, performance, and accessibility
SpacePlanner is a collaborative spatial design case study for Apple Vision Pro. It uses spatial presentation only where scale, placement, and shared context improve planning, and it treats comfort, accessibility, tracking loss, and exit as core product behavior.
Product decision
How do transform conflicts, large assets, shared sessions, captions, and nonspatial alternatives work together?
The smallest useful vertical slice is concrete: Merge intent-level edits, stream level-of-detail assets progressively, and provide text, audio, keyboard, and two-dimensional alternatives.
Boundaries that keep the design honest
- Keep projects, transforms, placement intent, undo, and merge policy independent of RealityKit entity lifetime.
- Choose windows, volumes, and immersion from the task, with predictable transitions and an obvious user-controlled exit.
- Load bounded assets progressively and measure frame time, memory, thermal behavior, tracking recovery, and visual stability on hardware.
- Provide accessible labels, captions, contrast, reduced-motion behavior, keyboard or voice paths, and a useful nonspatial alternative.
- Avoid this failure: Applying last-write-wins to an entire scene or requiring spatial input as the only path.
Release evidence
No SpacePlanner visionOS target, RealityKit scene, ARKit session, asset pipeline, shared session, tracking-loss scenario, accessibility audit, frame profile, comfort review, or Apple Vision Pro device run was exercised.
This chapter records product and architecture decisions. Apple SDK behavior still requires the matching Xcode target, configured service or entitlement where applicable, and named Simulator or physical-device evidence. The browser Swift runner does not validate these Apple SDK surfaces.
Series navigation
- Previous: Part 138: SpacePlanner RealityKit, ARKit, interaction, and rendering
- Next: Part 140: SpacePlanner testing and release review
- Series index: Zero to iOS Hero