SpacePlanner testing and release review
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 should spatial interaction, tracking loss, performance, comfort, collaboration, and accessibility be verified?
The smallest useful vertical slice is concrete: Layer domain and merge tests with device interaction checks, frame profiling, tracking-loss recovery, accessibility review, and a comfort ledger.
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: Treating simulator success as physical-device or comfort evidence.
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 139: SpacePlanner persistence, collaboration, performance, and accessibility
- Next: Series complete
- Series index: Zero to iOS Hero