RealityKit und das räumliche Mentalmodell

SwiftUI auf visionOS liefert Ihnen ein Fenster im 3D-Raum. RealityKit liefert Ihnen den Rest des Zimmers. Der Unterschied liegt im Mentalmodell, und das Mentalmodell ist die Architektur.

Eine SwiftUI-Entwicklerin, die zum ersten Mal auf visionOS trifft, neigt dazu, dieselben Strukturen zu bauen wie auf iOS: eine WindowGroup mit Views darin. Das Ergebnis ist ein flaches Panel, das im Raum schwebt. Das Panel ist für viele Apps in Ordnung. Der Raum um das Panel herum ist das, was visionOS hinzufügt, und der Raum ist das Hoheitsgebiet von RealityKit.

RealityKit ist nicht SwiftUI in 3D. Die Architektur unterscheidet sich in der Form, nicht nur in der Dimension. SwiftUI ist ein wertegetypter View-Baum mit einer Result-Builder-DSL über einem Beobachtungssystem; die Aufgabe des Frameworks besteht darin, das nächste Rendering aus dem aktuellen Zustand zu berechnen. RealityKit ist ein Entity-Component-System (ECS) mit einem Szenengraphen, der in Ankern verwurzelt ist, die virtuelle Entities an Referenzpunkte der realen Welt binden; die Aufgabe des Frameworks besteht darin, eine 3D-Szene zu pflegen, während sich Benutzer und Welt darum herum bewegen. Dasselbe Swift-Projekt kann beide gleichzeitig verwenden, und die Grenze zwischen ihnen ist der Ort, an dem die meisten Fehler im räumlichen Design passieren.

Der Beitrag durchläuft das räumliche Mentalmodell. Fünf konkrete Arten, wie sich das Modell von einem SwiftUI-Fenster unterscheidet, und die Routing-Frage, wann welches Framework die richtige Antwort ist.

TL;DR

• RealityKit ist ein Entity-Component-System (ECS). Eine Entity ist ein Knoten; Components sind typisierte Daten, die an den Knoten angehängt werden; Systems führen Logik über Entities aus, die bestimmte Komponenten-Kombinationen haben.
• Anker binden virtuelle Entities an Referenzpunkte der realen Welt. RealityKit stellt Ankerziele über AnchoringComponent.Target (.world, .head, .hand(_:location:), .plane(...), .image(...), .referenceObject(...)) bereit. Auf visionOS liefert ARKit die zugrunde liegenden Anker-Structs (WorldAnchor, HandAnchor, ImageAnchor, ObjectAnchor, PlaneAnchor), die ARKit über Anker-Update-Streams meldet.
• Eine 3D-Szene ist kein View-Baum. Die Render-Schleife läuft kontinuierlich, der Szenengraph mutiert über die Zeit, und die Rendering-Schicht ist GPU-getrieben (Metal darunter) und nicht diff-basiert.
• RealityView ist die SwiftUI-Brücke. Sie platziert eine RealityKit-Szene innerhalb eines SwiftUI-View-Baums; die Grenze ist einseitig (SwiftUI hostet RealityKit, nicht umgekehrt).
• Die Routing-Regel: Wenn der Benutzer ein Fenster möchte, liefern Sie SwiftUI aus. Wenn der Benutzer den Raum möchte, liefern Sie RealityKit aus. Apps, die beides benötigen, platzieren ein RealityView innerhalb eines SwiftUI-Fensters und akzeptieren, dass sich die beiden Hälften explizit koordinieren.

Fünf Unterschiede zu einem SwiftUI-Fenster

Die Form ändert sich in dem Moment, in dem Sie etwas außerhalb des Panels platzieren. Fünf Unterschiede sind wichtig.

1. Entity-Component-System, nicht View-Body-State

Ein SwiftUI-View ist ein wertegetypter Typ mit einer berechneten body-Eigenschaft und einem Zustand, der durch Property-Wrapper gestützt wird.¹ Das Framework führt den Body erneut aus, wenn sich der Zustand ändert; das Diff fließt in den Renderer ein.

Eine RealityKit-Entity ist ein referenzgetyptes Objekt, das in einem Szenengraphen sitzt. Components sind typisierte Structs, die an Entities angehängt werden (ModelComponent, Transform, CollisionComponent, PhysicsBodyComponent, eigene Component-Typen, die Sie definieren).² Systems sind Typen, die dem System-Protokoll entsprechen; das Framework führt jedes registrierte System einmal pro Frame aus, und System.update(context:) (typischerweise mutating bei einem Struct) ist der Ort, an dem das System die Components der Entities liest und schreibt, die mit seiner Abfrage übereinstimmen.

import RealityKit

let cube = Entity()
cube.components.set(ModelComponent(
    mesh: .generateBox(size: 0.1),
    materials: [SimpleMaterial(color: .blue, isMetallic: false)]
))
cube.components.set(InputTargetComponent())
cube.components.set(CollisionComponent(shapes: [.generateBox(size: [0.1, 0.1, 0.1])]))

Der Würfel hat keinen body. Der Würfel hat eine Menge von Components. Das Hinzufügen von InputTargetComponent und CollisionComponent ist das, was den Würfel auf Gesten reagieren lässt; entfernen Sie sie, und Gesten gehen direkt durch zu der Entity dahinter. Das Hinzufügen von PhysicsBodyComponent ist das, was den Würfel unter Schwerkraft fallen lässt; entfernen Sie es, und der Würfel schwebt. Die Komposition der Components bestimmt das Verhalten der Entity.

Die mentale Verschiebung: In SwiftUI beschreiben Sie, was als Funktion des Zustands auf dem Bildschirm sein soll. In RealityKit beschreiben Sie, was eine Entity ist (ihre Components), und lassen die Systems entscheiden, was mit ihr passiert.

2. Anker, nicht Koordinaten

Das Koordinatensystem eines SwiftUI-Views ist das Fenster. Position 0,0 ist die obere linke Ecke; Positionen werden in Punkten angegeben; der Frame des Views ist sein Raum. Das Fenster ist das Universum.

Das Koordinatensystem einer RealityKit-Szene hängt von ihrem Anker ab. Die Verankerungsschicht hat zwei Gesichter. RealityKits AnchorEntity (gesteuert durch ein AnchoringComponent.Target) ist das, worauf Sie eine Entity platzieren; die Anker-Structs von ARKit sind die zugrunde liegenden Daten, die das System verwendet, um das Ziel mit der realen Welt synchron zu halten.³

Die RealityKit-Ankerziele, nach denen Sie innerhalb einer AnchorEntity oder eines AnchoringComponent greifen, sind:

• .world(transform:): ein Punkt im realen Raum, definiert durch eine Transformation
• .head: an die Kopfhaltung des Benutzers gebunden; die Entity folgt dem Blick des Benutzers
• .hand(_:location:): an ein bestimmtes Handgelenk gebunden (Handfläche, Fingerspitze, Handgelenk usw.)
• .plane(...): an eine erkannte horizontale oder vertikale Oberfläche gebunden (Tisch, Wand, Boden)
• .image(...) / .referenceImage(...): an ein erkanntes 2D-Bild in der Umgebung gebunden
• .referenceObject(...): an ein erkanntes reales 3D-Objekt gebunden

Auf visionOS liefert ARKit die zugrunde liegenden Ankerdaten über WorldAnchor-, HandAnchor-, ImageAnchor-, ObjectAnchor- und PlaneAnchor-Structs, die über Anker-Update-Provider von ARKitSession ausgeliefert werden. (Body Tracking ist auf Apples Body-Tracking-Oberfläche nur für iOS/iPadOS verfügbar; visionOS stellt .body nicht als RealityKit-Ankerziel bereit.)

Der Anker ist das, was die Szene „real” macht. Ein virtuelles Schachbrett, das auf einem .plane-Ziel für den Tisch des Benutzers platziert ist, bleibt auf dem Tisch, wenn der Benutzer um ihn herumgeht; ein Schachbrett, das an festen Koordinaten relativ zu einem .head-Ziel platziert ist, folgt dem Kopf des Benutzers und fühlt sich wie eine Halluzination an.

Die mentale Verschiebung: Position ist keine Zahl. Position ist was ist der Anker, und wo befindet sich die Entity relativ zum Anker. Ein virtuelles Objekt ohne sinnvollen Anker ist eine Halluzination; der Anker ist das, was dem Benutzer sagt, dass das Objekt zum Raum gehört.

3. Kontinuierliche Render-Schleife, nicht diff-basiert

SwiftUI rendert, wenn sich der Zustand ändert. Das Framework entscheidet, wann ein Re-Rendering nötig ist, und berechnet die minimale Baumänderung. Zwischen den Renderings ist der Bildschirm statisch.

RealityKit treibt eine Frame-basierte Simulations- und Rendering-Schleife an. Der Szenengraph mutiert über die Zeit, da Physik, Animationssysteme und Eingabe-Handler Entity-Transformationen und Komponentenwerte aktualisieren, und der Renderer (Metal-gestützt) zeichnet die aktive Szene in jedem Frame. Per-Frame-Logik lebt in System.update(context:); dieser Hook ist die Einladung des Frameworks, die Szene bei jedem Tick zu mutieren.⁴

Die mentale Verschiebung: Zeit ist Teil der Szene. Ein SwiftUI-View-Body, der einmal läuft, ist in Ordnung; eine RealityKit-Entity muss berücksichtigen, was in Frame N+1, N+2, N+3 passiert. Die update(context:)-Methode auf einem benutzerdefinierten System ist der Ort, an dem Sie Per-Frame-Logik schreiben; der Component-Wert, den Sie innerhalb von update mutieren, ist das, was der Renderer beim nächsten Durchlauf liest.

4. RealityView ist die Brücke, in einer Richtung

SwiftUI-Views komponieren andere SwiftUI-Views. RealityKit-Entities komponieren andere RealityKit-Entities. Die Grenze zwischen den beiden ist RealityView, ein SwiftUI-View-Typ, der eine RealityKit-Szene hostet.⁵

import SwiftUI
import RealityKit

struct ContentView: View {
    var body: some View {
        RealityView { content in
            // Build the scene
            let cube = Entity()
            cube.components.set(ModelComponent(
                mesh: .generateBox(size: 0.1),
                materials: [SimpleMaterial(color: .blue, isMetallic: false)]
            ))
            content.add(cube)
        } update: { content in
            // Mutate the scene in response to SwiftUI state changes
        }
    }
}

Die make-Closure läuft einmal, wenn der View zum ersten Mal erscheint. Die update-Closure läuft, wann immer sich der SwiftUI-Zustand, von dem der View abhängt, ändert. In beiden Closures haben Sie über den content-Parameter Zugriff auf die RealityKit-Szene; Sie fügen Entities hinzu, mutieren Transformationen, registrieren Systems.

Die Grenze ist einseitig. SwiftUI hostet RealityKit. RealityKit hostet kein SwiftUI; Sie können kein SwiftUI-View „innerhalb” einer Entity platzieren und erwarten, dass es als Teil der 3D-Szene gerendert wird, so wie ein SwiftUI-Subview innerhalb eines Parents gerendert wird. Die Ausnahme sind Attachments (im Parameter attachments: von RealityView): Sie deklarieren benannte SwiftUI-Views, rufen sie als ViewAttachmentEntity-Werte ab und positionieren und skalieren sie innerhalb der 3D-Szene wie jede andere Entity.⁵ Attachments sind keine eingebetteten SwiftUI-Views innerhalb einer Entity; es sind 2D-SwiftUI-Oberflächen, die als Entities verpackt sind, die der Renderer in 3D platzieren kann. Standardmäßig behalten sie eine feste Ausrichtung bei; wenn sie dem Träger zugewandt sein sollen, hängen Sie eine BillboardComponent an die Attachment-Entity an.

5. Gesten in 3D sind anders

SwiftUI-Gesten (.onTapGesture, DragGesture usw.) operieren im Bildschirmraum. Das System weiß, wo der Finger relativ zum View ist; das Framework verteilt basierend auf Hit-Testing in 2D.

RealityKit-Gesten operieren im Szenenraum.⁶ Das System weiß, wohin der Benutzer schaut (der Blickstrahl), wo die Hände des Benutzers sind (Handgelenke des Hand-Trackings) und mit welcher Entity der Blick + Tap sich schneidet. Das Verteilungsmodell ist „der Benutzer hat auf diese Entity geschaut und gepincht”; das Äquivalent eines Taps.

Damit eine Entity Gesten empfangen kann, benötigt sie InputTargetComponent und ein CollisionComponent, das die Hit-Test-Geometrie definiert. Ohne InputTargetComponent ist die Entity für das Gestensystem unsichtbar; ohne CollisionComponent hat das Gestensystem keine Form, gegen die getestet werden kann. Beide müssen vorhanden sein.

Die mentale Verschiebung: Gestenziele sind keine Bildschirmregionen. Gestenziele sind 3D-Entities, die sich explizit für die Eingabe entschieden haben. Der Rest der Szene ist „Dekoration, durch die der Benutzer hindurchsehen kann.”

Wann SwiftUI ausreicht

Eine gängige visionOS-App benötigt RealityKit nicht. Drei Muster, bei denen SwiftUI allein die richtige Antwort ist:

Fensterförmige Apps ohne räumlichen Inhalt. Ein Meditationstimer, ein Notizbuch, ein Einstellungsbereich, eine Chat-Oberfläche. Die App besteht aus Informationen, die Sie über 2D-Affordanzen lesen oder mit denen Sie interagieren. Sie in eine WindowGroup zu platzieren und flach zu halten, ist die richtige Entscheidung. visionOS behandelt SwiftUI-Fenster als schwebende Glaspaneele mit System-Chrome; der Benutzer erhält eine angenehme Leseerfahrung, ohne dass Sie eine Zeile RealityKit schreiben müssen.

Multi-Window-Apps, die flache Paneele im Raum komponieren. Ein Code-Editor mit separaten Fenstern für den Editor, das Terminal und die Dokumentation. Der Benutzer möchte die Fenster im 3D-Raum angeordnet haben (links, rechts, hinten), aber jedes Fenster ist selbst ein SwiftUI-View. Die 3D-Anordnung ist Aufgabe des Betriebssystems; die Paneele sind flach.

Dokumentationsbetrachter, Fotogalerien, Videoplayer. Inhalte, die der Benutzer durch das Panel konsumiert. Das Panel ist die Rendering-Oberfläche; die dritte Dimension ist nur die räumliche Position des Panels im Raum.

Die Regel: Wenn der Inhalt 2D ist (Text, Bilder, Video, Steuerelemente), ist das richtige Framework SwiftUI. Die dritte Dimension ist, wo das Panel positioniert ist, nicht das, was darin gerendert wird.

Wann RealityKit erforderlich ist

Die Fälle, in denen SwiftUI nicht ausreicht:

3D-Inhalte, um die der Benutzer herumgehen kann. Ein virtuelles Objekt auf dem Tisch des Benutzers (ein Modellauto, eine Skulptur, ein Gebäude). Das Objekt hat Volumen; der Benutzer kann sich um es herumbewegen; das Objekt sollte korrekt mit dem Raum verdeckt werden. Das richtige Framework ist RealityKit, verankert an einem .plane-Ziel.

Räumliche UI, die auf den Raum reagiert. Schaltflächen, die über einer realen Tastatur schweben, Anmerkungen, die an einem realen Objekt angebracht sind, ein virtuelles Maßband, das entlang einer realen Wand gelegt wird. Die Position der UI wird durch die Geometrie der Welt bestimmt, nicht durch den Koordinatenraum eines Fensters. RealityKit-Anker übernehmen die Bindung; SwiftUI-Attachments innerhalb eines RealityView liefern die 2D-Affordanzen.

Kontinuierliche räumliche Simulation. Ein Vogelschwarm, ein Ball, der über den Boden rollt, eine Flüssigkeitssimulation, alles, wo sich der Szenenzustand über die Zeit entwickelt. Die kontinuierliche Render-Schleife ist das richtige Werkzeug; SwiftUIs diff-basierter Renderer würde entweder Frames verpassen oder Akkulaufzeit verbrauchen.

Hand-Tracking-Interaktionen. Pinch-zum-Greifen, zweihändiges Skalieren, Zeichnen in der Luft. Das Eingabemodell erfordert ARKits HandTrackingProvider (mit HandAnchor-Updates) plus ein .hand(_:location:)-Ankerziel; SwiftUI stellt diese Oberfläche nicht bereit.

Body-Tracking-AR. Spiegelung der Pose des Benutzers auf einen virtuellen Charakter, Verfolgung des Körpers des Benutzers für eine Fitness-App, Erkennung realer Objekte. Die Erfassung und Inferenz finden in ARKit statt (RealityKits Begleiter auf niedrigerer Ebene); RealityKit rendert das Ergebnis.

Die Regel: Wenn der Inhalt 3D ist und im Raum lebt (volumetrisch, verankert, simuliert oder handgesteuert), ist das richtige Framework RealityKit. SwiftUI ist das Chrome darum herum.

Das Kompositionsmuster

Die meisten nicht-trivialen visionOS-Apps verwenden am Ende beides. Das Muster, das sich gut ausliefern lässt:

1. Das Chrome der App (Einstellungen, Navigation, Listen, Formulare, Inspektor-Paneele) lebt in SwiftUI-Fenstern.
2. Die räumliche Szene (der volumetrische Inhalt, den der Benutzer manipuliert) lebt in einem RealityView innerhalb eines eigenen Fensters oder Volumens.
3. Die beiden kommunizieren über SwiftUI-Zustand. Eine Schaltfläche in einem SwiftUI-Panel schaltet einen @State-Boolean um; die update:-Closure des RealityView liest den Boolean und mutiert die Entity in der Szene.
4. Zustandsänderungen auf der RealityKit-Seite, die an SwiftUI weitergegeben werden müssen, gehen über Callbacks, die die make:-Closure des RealityView registriert (subscribe(to:) auf dem Event-Publisher der Szene).⁷

struct GalleryView: View {
    @State private var selectedSculpture: SculptureID?

    var body: some View {
        HStack {
            // SwiftUI side: list of sculptures
            List(allSculptures) { sculpture in
                Button(sculpture.name) {
                    selectedSculpture = sculpture.id
                }
            }
            .frame(width: 300)

            // RealityKit side: 3D rendering of the selected sculpture
            RealityView { content in
                // Build initial scene
            } update: { content in
                guard let id = selectedSculpture else {
                    content.entities.removeAll()
                    return
                }
                // Mutate scene to show the selected sculpture
                presentSculpture(id, in: content)
            }
        }
    }
}

Die Aufteilung ist ehrlich darüber, welches Framework welche Aufgabe besitzt. SwiftUI besitzt die Liste, die Schaltflächen, das Layout, den Zustand. RealityKit besitzt das 3D-Rendering, die Entities, die kontinuierliche Simulation. Der Zustand überschreitet die Grenze als ein einziger @State-Wert; keines der beiden Frameworks greift in das andere hinein.

Was ich in meinem Stack anders bauen würde

Drei Muster, die leicht zu erkennen sind, sobald Sie eine räumliche Szene ausgeliefert haben:

Anker zuerst, Entity danach. Wenn Sie ein Feature entwerfen, entscheiden Sie sich für den Anker, bevor Sie sich für die Geometrie entscheiden. Ein virtuelles Instrument, das an der Hand des Benutzers verankert ist, ist ein anderes Produkt als dasselbe Instrument, das an einem .plane-Ziel auf dem Tisch verankert ist. Der Anker entscheidet über die Beziehung des Benutzers zum Objekt; die Geometrie ist Implementierungsdetail.

Components, keine Subklassen. Es ist verlockend, von Entity abzuleiten, um Domänentypen wie ChessPiece: Entity zu bauen. Das Kompositionsmuster schlägt Vererbung jedes Mal: Eine Schachfigur ist eine Entity mit einem ChessPieceComponent (eigene Daten: Farbe, Typ, Position), einem ModelComponent (das 3D-Mesh), einem InputTargetComponent und einem CollisionComponent. Neue Verhaltensweisen sind neue Components, keine neuen Subklassen.

Systems für übergreifende Logik. Wenn zehn Entities dasselbe Verhalten benötigen (Schwerkraft, Kollisionsantwort, Audio-Dämpfung, Gestenzustand), schreiben Sie ein System, das auf den relevanten Components operiert. Das System läuft einmal pro Frame über alle übereinstimmenden Entities. Die Alternative (die Logik auf jeder Entity zu platzieren) erzeugt den n-mal-n-Frames-Bug, den das ECS-Muster vermeiden sollte.

Wann RealityView die falsche Antwort ist

Einige Fälle, in denen das Greifen nach RealityView die falsche Wahl ist:

Einzelnes 3D-Bild, keine Interaktion. Ein statisches 3D-Logo oder Produkt-Rendering. Verwenden Sie stattdessen einen SwiftUI-Model3D-View.⁸ Model3D ist der billige Pfad für „lade ein USDZ und zeige es an”; RealityView ist für Szenen, die Sie aufbauen und mutieren.

iOS-Apps mit einfachen AR-Overlays. ARKits ARView (die ältere Oberfläche) oder die iOS-seitige ARView-Integration von RealityKit ist oft die richtige Wahl, wenn das AR-Erlebnis ein Feature innerhalb einer größeren iOS-App ist. RealityView ist Swift-und-SwiftUI-nativ und lebt gut innerhalb von SwiftUI; ältere ARView-Workflows sind manchmal einfacher, wenn der Rest der App UIKit ist.

2D-Zeichnen auf einem Panel. Ein Whiteboard, ein Foto-Anmerkungs-Tool, ein Editor für flache Formen. Das richtige Werkzeug ist Canvas (SwiftUIs Metal-gestützte Zeichenoberfläche) oder MetalView. RealityView ist überdimensioniert, wenn Sie nicht im 3D-Raum bauen.

Was das Muster für Apps bedeutet, die auf visionOS 2+ ausgeliefert werden

Drei Erkenntnisse.

1. RealityKit und SwiftUI komponieren; sie verschmelzen nicht. Verwenden Sie SwiftUI für fensterförmiges Chrome und 2D-Affordanzen; verwenden Sie RealityKit für den raumförmigen 3D-Inhalt. Die Grenze ist RealityView, und die Grenze ist einseitig.

2. Das Mentalmodell ist ECS plus Anker. Eine Entity ist das, woraus sie zusammengesetzt ist. Ein Anker entscheidet, wie sich die Entity zum realen Raum des Benutzers verhält. Das Paar (Components, Anker) ist die Designeinheit.

3. Die Render-Schleife ist kontinuierlich. Zeit ist Teil der Szene. Per-Frame-Logik gehört in System.update(context:); per-State-Change-Logik gehört in RealityView.update:. Das Vermischen der beiden Schichten (Per-Frame-Logik im Body von SwiftUI schreiben, zustandsgetriebene Logik in System.update schreiben) ist der häufigste Architekturfehler.

Das vollständige Apple-Ecosystem-Cluster: typisierte App Intents für Apple Intelligence; MCP-Server für übergreifende LLM-Agenten; die Routing-Frage zwischen ihnen; Foundation Models für On-Device-LLM und das Tool-Protokoll; Live Activities für die State Machine des iOS-Sperrbildschirms; der watchOS-Runtime-Vertrag auf der Apple Watch; SwiftUI-Internas für das Framework-Substrat; Liquid-Glass-Muster für die visuelle Schicht; Multi-Plattform-Auslieferung für geräteübergreifende Reichweite. Der Hub befindet sich in der Apple Ecosystem Series. Für den breiteren Kontext von iOS mit AI-Agenten siehe den iOS Agent Development Guide.

FAQ

Ist RealityKit ein Ersatz für SwiftUI auf visionOS?

Nein. RealityKit und SwiftUI komponieren. SwiftUI verwaltet 2D-Fenster, Steuerelemente und Chrome; RealityKit verwaltet 3D-Szenen, die an Referenzpunkte der realen Welt verankert sind. Die meisten nicht-trivialen visionOS-Apps verwenden beides, mit RealityView als Brücke, die eine RealityKit-Szene innerhalb eines SwiftUI-View-Baums platziert.

Wann sollte ich RealityView vs. Model3D verwenden?

Verwenden Sie Model3D zum Anzeigen eines einzelnen statischen 3D-Assets (eine USDZ-Datei, ein einzelnes Produkt-Rendering). Verwenden Sie RealityView zum Aufbauen oder Mutieren einer 3D-Szene über die Zeit (mehrere Entities, Physik, Gesten, Hand-Tracking, verankerte Inhalte). Model3D ist der billige Pfad; RealityView ist die vollständige ECS-Oberfläche.

Was ist der Unterschied zwischen einer Entity und einer Component in RealityKit?

Eine Entity ist ein Knoten im Szenengraphen. Eine Component ist typisierte Daten, die an den Knoten angehängt sind. ModelComponent gibt der Entity ein Mesh; InputTargetComponent macht sie gestenfähig; CollisionComponent definiert die Hit-Test-Geometrie; PhysicsBodyComponent lässt sie auf Schwerkraft reagieren. Eigene Component-Typen, die Sie definieren, halten Domänendaten. Verhalten ist Komposition über Vererbung: Das Verhalten einer Entity ist die Summe ihrer Components.

Was sind Anker, und warum sind sie wichtig?

Anker binden virtuelle Inhalte an Referenzpunkte der realen Welt: den Kopf des Benutzers, die Hand, eine erkannte Oberfläche, ein erkanntes Bild, ein erkanntes Objekt oder einen persistenten Weltpunkt. Der Anker entscheidet über die Beziehung des Benutzers zur Entity. Ein virtuelles Objekt auf einem .plane-Ziel (dem Tisch) bleibt stehen, wenn der Benutzer herumgeht; ein virtuelles Objekt auf einem .head-Ziel folgt dem Kopf des Benutzers. Die Wahl des richtigen Ankers ist die erste Designentscheidung in einem räumlichen Feature.

Kann RealityKit auf iOS laufen, nicht nur auf visionOS?

Ja. RealityKit wird auf iOS, iPadOS, macOS und visionOS ausgeliefert. ARKit-getriebene AR-Erlebnisse verwenden die iOS-Oberfläche von RealityKit. Die visionOS-Oberfläche fügt räumlich-spezifische Ankertypen hinzu (Kopf, Hand, Welt), die iOS nicht bereitstellt; das Kern-ECS-Muster wird gemeinsam genutzt.

Referenzen