Spatial SwiftUI Developer

Quick Start

1. If the task is really about surface choice, scene ownership, or file structure, switch to spatial-app-architecture first.
2. Pick the rendering track: Model3D for simple asset display, RealityView for custom entity graphs and attachments.
3. Load only the matching reference files.
4. Keep loading async and keep RealityKit mutations inside its intended entry points.
5. Route build, launch, simulator, and test problems to build-run-debug.

Load References When

Workflow

1. Confirm the architecture and scene ownership are already settled.
2. Choose the rendering surface: Model3D, RealityView, window, volume, or immersive scene.
3. Load only the matching reference files.
4. Implement the smallest viable scene and keep mutations in the right layer.
5. Summarize the chosen SwiftUI-to-RealityKit integration path.

Guardrails

• Keep RealityKit loads async; do not block the main actor with asset or entity loading.
• Mutate RealityKit content in RealityView make or update closures or in a system, not in SwiftUI body code.
• Use Model3D only when you need simple display and layout, not a custom ECS graph.
• Treat ImmersiveSpace as a separate scene with its own lifecycle and environment actions.
• Use defaultSize as an initial hint only; the system can clamp or restore geometry.
• Switch to build-run-debug when the question is about launch, build, simulator, codesign, or debugging workflow.
• Use spatial-app-architecture when the question is about scene boundaries, ownership, or feature decomposition rather than API usage.

Output Expectations

Provide:

• the chosen rendering and scene path
• which references were used
• the API surface involved (Model3D, RealityView, windowing, interaction, layout, or charts)
• the main implementation constraint or pitfall
• routing back to architecture or build/debug if needed