So startest du mit der Entwicklung von VR-/AR-Anwendungen

2026 ist der Einstieg in XR zugleich einfacher und schwieriger geworden. Einfacher, weil Apple, Google und Meta inzwischen ziemlich klare Einstiegswege anbieten: Apple hat visionOS mit SwiftUI und RealityKit, Google hat Android XR mit Jetpack XR, Unity, OpenXR und WebXR, und Meta hat Meta Horizon OS mit offizieller Unterstützung für Unity, Unreal Engine, Native/OpenXR, Android-Apps und Web. Schwieriger ist es geworden, weil der typische Anfängerfehler heute nicht mehr darin besteht, "die falsche Sprache" zu wählen, sondern auf der falschen Plattform zu starten. (Apple, Google, Meta)

Wenn man es auf den Punkt bringt, lautet die erste wirkliche Frage in XR heute nicht mehr "Unity oder Unreal?", sondern auf welchem Gerät und für welchen Anwendungsfall dein erster funktionierender Prototyp laufen soll. Eine einfache VR-Trainingsanwendung für ein Headset, ein räumliches Interface für Apple Vision Pro, eine AR-Funktion für Android-XR-Brillen und ein plattformübergreifendes 3D-Erlebnis auf Basis von OpenXR sind vier sehr unterschiedliche Wege, auch wenn auf Konferenzen gern alles unter dem Label XR zusammengeworfen wird. (Apple, Google, Khronos)

Wähle zuerst die Plattform, nicht die Engine

Wenn du den praktischsten Einstieg in vollwertige Headset-Anwendungen suchst, ist Meta Quest meistens der vernünftigste Startpunkt. Im offiziellen Developer-Portal von Meta ist das Ökosystem bereits klar in mehrere Wege aufgeteilt: Unity, Unreal Engine, Native/OpenXR, Meta Spatial SDK, Android-Apps und Web. Gleichzeitig beschreibt Meta die Quest-Geräte als gemeinsame Entwicklerplattform auf Basis von Meta Horizon OS, und die aktuellen Headsets teilen sich einen gemeinsamen Grundstock an Funktionen wie Boundary, Passthrough und Hand Tracking. Genau das macht Quest zu einem sehr dankbaren Einstieg, wenn du möglichst schnell eine echte VR-/MR-Szene auf realer Hardware sehen willst, statt dich wochenlang nur durch Doku zu arbeiten. (Meta, MetaQuest)

Wenn dich eher räumliche Interfaces im Apple-Ökosystem interessieren, dann führt der natürliche Weg zu visionOS. Apple empfiehlt, mit einem neuen Projekt in Xcode zu beginnen, und positioniert SwiftUI als den primären Weg für die Entwicklung unter visionOS: Darüber bekommst du den vollen Zugriff auf die Plattform, und einige ihrer besonderen Funktionen sind sogar ausschließlich darüber verfügbar. Gleichzeitig gibt Apple dir von Anfang an ein klares Denkmodell mit: Window für überwiegend 2D-Inhalte, Volume für 3D-Inhalte und Immersive Space für vollständige Immersion. Das ist ein starker Weg für Produktivitäts-Apps, Lernanwendungen, Design Review und räumliche UI im Allgemeinen, auch wenn der Einstieg hardwareseitig nicht gerade günstig ist. (Apple, AppleDocs)

Wenn du in ein Ökosystem einsteigen willst, das sich rund um neue Headsets und Brillen aufbaut, dabei aber näher an Android bleiben möchtest, solltest du dir Android XR ansehen. Google positioniert Android XR als Plattform für XR-Headsets, kabelgebundene XR-Brillen und AI Glasses. In der offiziellen Developer-Doku kannst du über Jetpack XR SDK, Unity, OpenXR oder WebXR entwickeln. Google betont außerdem ausdrücklich, dass viele bestehende Android-Apps auf XR-Geräten bereits als 2D-Panels in einem 3D-Raum laufen können. Für Android-Teams ist das ein echter Vorteil, weil die Einstiegshürde oft niedriger ist als beim Sprung in ein komplett fremdes Ökosystem. (Google, GoogleBlog)

Wenn dir plattformübergreifende Portabilität wichtiger ist als ein schneller erster Release, dann wird OpenXR interessant. Khronos positioniert es als royalty-free Standard für XR-Plattformen und Geräte, und genau darin liegt der große Reiz in einem fragmentierten Markt. Gleichzeitig zeigt das offizielle OpenXR Tutorial ziemlich ehrlich, was das in der Praxis bedeutet: Du brauchst Verständnis für Grafik-APIs, das Runtime-Modell, CMake, deine IDE und einen deutlich stärker engineering-lastigen Workflow als bei einer fertigen Engine. Mächtig ist das allemal, aber für Einsteiger ist es selten der sanfteste erste Schritt. (Khronos, OpenXRTutorial)

Und dann gibt es noch WebXR. Ich würde das vor allem als guten Weg für Demos, Lernszenen und leicht teilbare Prototypen sehen, die sich einfach über einen Link öffnen lassen. Sowohl Google als auch Meta führen Web als offiziellen Teil ihrer XR-Entwicklungspfade. Wenn du aber tiefe Geräteintegration, reichhaltigere Interaktionen und besser vorhersehbare Performance willst, ist der Browser 2026 noch immer eher ein praktischer Auslieferungskanal als das Standardfundament für ein ernsthaftes XR-Produkt. (Google, Meta)

Wie du den richtigen Stack wählst, ohne es unnötig kompliziert zu machen

Für einen ersten ernstzunehmenden Prototypen ist Unity in den meisten Fällen nach wie vor die sicherste Allround-Wahl. Das hat hier zwei große Vorteile. Erstens bringt XR Interaction Toolkit bereits High-Level-Bausteine für Hover, Select, Grab, haptisches Feedback, UI-Interaktionen, Locomotion und XR Origin mit. Zweitens gibt es den XR Interaction Simulator, mit dem du einen Teil deiner Logik testen kannst, ohne ständig das Headset aufsetzen zu müssen. Für AR-Szenarien verbindet Unity diesen Workflow außerdem direkt mit AR Foundation, sodass der Übergang von Mobile AR zu Headset XR relativ stimmig bleibt. (UnityToolkit)

Der zweite große Pluspunkt ist das offizielle OpenXR Plugin von Unity. Damit bleibst du in einem vergleichsweise komfortablen Engine-Workflow, ohne dir den Weg zu einer portableren Architektur abzuschneiden. Ja, du musst OpenXR trotzdem über XR Plug-in Management aktivieren, Features und Interaction Profiles auswählen und deine Projekteinstellungen validieren. Aber das ist immer noch deutlich sanfter, als den ersten XR-Stack fast komplett von Grund auf aufzubauen. (UnityOpenXR)

Unreal Engine würde ich dann empfehlen, wenn du wirklich High-Fidelity-Grafik, anspruchsvollere 3D-Szenen, einen Blueprint/C++-Pipeline oder ein Team brauchst, das Unreal bereits gut beherrscht. Epic deckt in seiner XR-Dokumentation praktisch den kompletten erwachsenen Werkzeugkasten ab: Projektvorlagen, Head-Mounted-Erlebnisse über OpenXR, Hand Tracking, Motion Controller, Eye Tracking, 3D-UI, Multi-User-Szenarien und Performance. Als erster XR-Stack passt Unreal aber in der Regel besser zu Leuten, die Unreal schon kennen, als zu Leuten, die erst noch die Grundlagen von XR-Entwicklung verstehen wollen. (Epic)

Dann gibt es noch den Fall natives visionOS. Wenn dein echtes Ziel Apple Vision Pro ist, solltest du nicht aus Gewohnheit Unity ins Projekt ziehen, nur weil das in der Games-Welt vertraut wirkt. Apple macht ziemlich klar, dass SwiftUI der Hauptweg in visionOS ist und dass ein Teil des plattformspezifischen Verhaltens davon abhängt. Für iOS- oder macOS-Entwickler ist das oft der natürlichere und produktivere Weg, als alte Game-Engine-Muster in eine räumliche UI-Anwendung hineinzupressen. (AppleDocs)

Was du für den Start wirklich brauchst

Für visionOS brauchst du einen Apple-silicon-Mac, Xcode und die Bereitschaft, notfalls erst einmal im Simulator zu starten. Apple sagt ausdrücklich, dass die Entwicklung für visionOS Apple silicon voraussetzt. Der Einstieg selbst ist dabei recht geradlinig: Projekt anlegen, den Typ der ersten Szene auswählen, bei Bedarf Reality Composer Pro für 3D-Assets ergänzen und sich dann schrittweise von einer Fensteroberfläche hin zu räumlicheren Erlebnissen vorarbeiten. (AppleDocs)

Für Android XR empfiehlt Google eine aktuelle Canary build von Android Studio, weil dort die neuesten XR-Tools zuerst verfügbar sind. Zusätzlich brauchst du Android SDK Build-Tools, Android Emulator, Platform-Tools und Layout Inspector. Die gute Nachricht ist: Google dokumentiert auch die Einrichtung virtueller XR-Geräte, sodass du deine ersten Schritte nicht zwingend schon am ersten Tag mit gekaufter Hardware machen musst. (AndroidSetup)

Für Meta Quest gibt es einen besonders praktischen Punkt: Meta sagt ausdrücklich, dass jedes Quest-Headset als Developer Kit genutzt werden kann. Gleichzeitig basiert die gesamte Produktlinie auf einer gemeinsamen Entwicklerplattform, während leistungsstärkere Geräte wie Quest 3 und 3S später gezielt über Device Targeting optimiert werden können. Das ist ein gesunder Start: ein Gerät, ein Szenario und kein vorschneller Kampf mit Fragmentierung. (MetaQuest)

Für Low-Level-OpenXR sind die Anforderungen deutlich höher. Das offizielle Tutorial spricht von einem Windows- oder Linux-PC zum Bauen des Codes, einer geeigneten IDE, einem echten XR-Gerät oder Android-basierten Headset, Kenntnissen einer Grafik-API, CMake 3.28.3+ und Python 3.6+ für den Build der SDK-Sources. Das macht den Weg nicht schlecht. Es bedeutet nur, dass er in eine andere Problemklasse fällt. (OpenXRTutorial)

Ein praktischer Plan für dein erstes MVP

Der brauchbarste Weg für Einsteiger sieht meistens ungefähr so aus.

Wähle genau eine Hauptplattform. Nicht "ich entwickle gleich für ganz XR", sondern "ich entwickle für Quest", "ich entwickle für visionOS" oder "ich entwickle für Android XR".
Baue dir die Minimalumgebung auf. IDE, SDK, Simulator oder Emulator und möglichst früh auch ein reales Gerät. Wenn du schon in der ersten Woche Input, Komfort und Performance testen kannst, hast du den richtigen Startpunkt gewählt.
Baue eine funktionierende Szene, nicht das ganze Produkt. Apple schlägt vor, mit Window oder Volume zu beginnen und Immersive Space später hinzuzufügen. Google trennt dagegen klar zwischen der Anpassung einer bestehenden Android-App und dem Bau einer neuen immersiven App. In beiden Fällen gilt dieselbe Idee: Erst einmal eine einzige stimmige räumliche Szene zum Laufen bringen. (AppleDocs, Google)
Baue einen vollständigen Interaction Loop. Zum Beispiel: auf ein Objekt zeigen und es auswählen, ein Element greifen und verschieben, ein einfaches Panel öffnen oder einen AR Anchor beziehungsweise einen Spatial-UI-Flow auslösen. Genau hier ist XR Interaction Toolkit besonders nützlich, weil es die typischen Interaktionsmuster bereits mitbringt. (UnityToolkit)
Prüfe Performance und Komfort frühzeitig. Unitys OpenXR-Doku hebt Render Mode, Latency Optimization und Depth Submission ausdrücklich hervor. Auch Epic behandelt XR-Performance als grundlegendes Thema und nicht als kosmetischen Feinschliff nach dem Release. In XR reicht "läuft irgendwie" nicht: Input Lag, Jitter oder schlechte Tiefenbehandlung können das gesamte Erlebnis ruinieren. (UnityOpenXR, Epic)
Erst danach solltest du über Cross-Platform nachdenken. OpenXR und moderne Engines reduzieren Fragmentierung, aber sie heben Unterschiede bei UX, Eingabemodellen und Komfortregeln zwischen Plattformen nicht einfach auf. (Khronos, Meta)

Die häufigsten Anfängerfehler

Den "besten Motor" auswählen wollen, bevor Gerät und Anwendungsfall überhaupt feststehen.
Multi-Platform zu planen, bevor auch nur ein sauberer Interaction Loop funktioniert.
UX und Interaktionsdesign zu unterschätzen. In XR ist das Interface keine dünne Schicht über der App, sondern Teil der Architektur.
Zu glauben, dass Simulator oder Emulator reale Hardware vollständig ersetzen. Für die ersten Schritte sind sie hervorragend, aber Hand Input, Passthrough, Komfort und Presence müssen trotzdem auf einem echten Gerät geprüft werden.
In Low-Level-OpenXR einzusteigen "für die Zukunft", obwohl die eigentliche Aufgabe nur darin besteht, einen ersten lebendigen Prototypen zu bauen und herauszufinden, ob XR-Entwicklung dir überhaupt liegt. (Apple, Google, OpenXRTutorial)

Wo du anfangen solltest

Wenn du komplett neu in XR bist und möglichst schnell ein Gefühl dafür bekommen willst, wie immersive Anwendungen funktionieren, dann starte mit Unity + Meta Quest oder mit Unity/OpenXR + dem Android-XR-Emulator. Das ist der kürzeste Weg zu einer funktionierenden Szene, grundlegenden Interaktionen und den ersten echten Performance-Grenzen. (Meta, Google, UnityToolkit)

Wenn du bereits im Apple-Ökosystem entwickelst und dir räumliche UI natürlicher vorkommt als eine spielartige Szene, dann ist der direkte Weg in visionOS + SwiftUI + RealityKit meistens sinnvoller. Apple hat diesen Pfad ziemlich geradlinig angelegt und macht auch nicht wirklich ein Geheimnis daraus, dass native Entwicklung dort der bevorzugte Weg ist. (AppleDocs)

Wenn dein Ziel dagegen darin besteht, eine Grundlage aufzubauen, die später auf mehrere Geräte und Hersteller ausgeweitet werden kann, dann lohnt sich der Blick auf Unity/OpenXR oder sogar auf einen stärker Low-Level-orientierten OpenXR-Stack. Aber auch dann ist es klüger, ein einziges Haupt-Testgerät zu wählen, statt plattformübergreifend im luftleeren Raum planen zu wollen. (UnityOpenXR, Khronos)

Kurzes Fazit

2026 startest du mit der Entwicklung von VR-/AR-Anwendungen am besten nicht mit einer Debatte über die "leistungsstärkste Engine". Entscheidend ist, drei Fragen klar zu beantworten: Welches ist dein erstes Gerät, welche Art von Experience baust du, und welche minimale Interaktion muss in der ersten Woche funktionieren.

Ein guter Start sieht heute fast langweilig aus, und genau deshalb funktioniert er: eine Plattform, ein SDK, eine Szene, eine funktionierende Interaktion. Sobald das steht, liest du nicht mehr nur über XR. Du bist mittendrin.