SpacePlanner architecture and asset pipeline
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 can projects, scenes, assets, anchors, transforms, and collaboration remain testable?
The smallest useful vertical slice is concrete: Define domain transforms and intent-level edits, then isolate asset loading, spatial persistence, rendering, and collaboration behind ports.
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: Passing RealityKit entities through domain, persistence, and synchronization code.
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 135: SpacePlanner product, comfort, and spatial design
- Next: Part 137: SpacePlanner windows, volumes, immersion, and input
- Series index: Zero to iOS Hero