„Wir brauchen eine AR-App“ ist meist der falsche Ausgangspunkt
Fast jedes AR-Projekt startet mit derselben Annahme: Das muss eine App werden. Manchmal stimmt das. Oft nicht – und genau die Installationshürde tötet die Erfahrung, bevor sie überhaupt jemand sieht.
Die eigentliche Frage lautet nicht „App oder keine App“ – sondern wie jemand die Erfahrung überhaupt zum ersten Mal erlebt, und ob die Bitte, vorher etwas zu installieren, diesen Moment übersteht.
Die Installations-Reibung, die niemand durchrechnet
Wenn jemand Ihre AR-Erfahrung über eine Anzeige, einen QR-Code auf der Verpackung, ein Messebanner oder einen Social-Media-Post entdeckt, sieht der ehrliche Funnel so aus: sehen, ausprobieren wollen, auf den Download-Bildschirm im App Store treffen – und für die überwältigende Mehrheit an genau dieser Stelle abbrechen. Discovery-getriebenes AR, das eine Installation voraussetzt, verliert den Großteil seines Publikums, bevor die eigentliche Erfahrung überhaupt lädt.
WebXR und Tools wie 8th Wall lösen genau dieses Problem: AR direkt aus dem Browser, gestartet über einen Link oder QR-Code, ohne Installation, einsatzbereit in Sekunden. Bei einer Produkt-Anprobe-Kampagne, einer Messevorführung oder allem, bei dem es genau darum geht, „das jetzt sofort auszuprobieren, egal wo man gerade ist“, ist der Verzicht auf die Installation kein nettes Extra – er entscheidet darüber, ob Menschen es ausprobieren oder einfach weiterscrollen.
Wo native AR tatsächlich gewinnt
Native AR, gebaut mit ARKit und ARCore innerhalb einer vollständigen App, rechtfertigt ihre Komplexität in unterschiedlichen Situationen:
Ihre Nutzer haben die App ohnehin regelmäßig geöffnet. Die Shopping-App eines Möbelhändlers, eine Heimwerker-App, zu der Menschen bei jedem Projekt zurückkehren – AR-gestützte Anprobe ist hier ein zusätzliches Feature innerhalb einer bestehenden Beziehung, nicht etwas, das eine komplett neue Installation nur für ein einziges Produkt verlangt.
Sie brauchen Tracking, das über mehrere Sitzungen hinweg bestehen bleibt. Raumgroße Anker, die sich merken, wo ein virtuelles Objekt platziert wurde, oder Messungen, die über mehrere Besuche hinweg genau bleiben müssen – dafür braucht es die tiefere Betriebssystem-Integration, die eine Browser-Sandbox nicht bietet.
Sie brauchen hardwarespezifische Fähigkeiten. LiDAR-Tiefensensorik auf neueren iPhones, präzise Verdeckung (virtuelle Objekte, die korrekt hinter realen Objekten verschwinden) oder Hand-Tracking auf der Meta Quest sind im Browser entweder gar nicht verfügbar oder deutlich schlechter. Hängt die Erfahrung von dieser Präzision ab, ist nativ die einzige echte Option.
Die Engine wählen, sobald die Plattform feststeht
Für Mobile Games, Casual AR und die meisten plattformübergreifenden Projekte ist Unity 6 die Standardwahl – ausgereiftes Tooling, breite Geräteunterstützung und ein großes Plugin-Ökosystem für AR-SDKs. Die Unreal Engine 5 verdient ihren Platz, wenn visuelle Qualität im Vordergrund steht: hochwertige 3D-Showcases, filmische Produktvisualisierung, alles, wo die Renderqualität explizit zur Marke gehört. Für installationsfreie Reichweite im Browser decken Three.js und WebXR interaktives 3D und AR ab, das nur einen Klick entfernt sein muss – nicht einen Download.
Apple Vision Pro und Meta Quest bilden eine eigene Kategorie: native visionOS/RealityKit-Apps und Quest-native Builds für wirklich immersive, raumgroße Erfahrungen, die ein Smartphone-Display oder ein Browser-Tab nicht nachbilden können – Trainingssimulationen, räumliche Design-Reviews, alles, worum es geht, in der Erfahrung zu sein, statt sie durch ein Rechteck zu betrachten.
Ein einfacher Test vor der Entscheidung
Stellen Sie eine Frage: Wird das Ganze einmalig erlebt, von jemandem, der schnell entscheidet, ausgehend von einer Anzeige oder einem Link – oder ist es ein wiederkehrendes Feature für Menschen, die Ihre App ohnehin schon geöffnet haben? Einmalig und schnell → WebXR, ohne Installation, jede Reibung zwischen Sehen und Ausprobieren entfernen. Wiederkehrend und app-nativ → in die native Erfahrung einbauen, der Ihre Nutzer bereits vertrauen.
Das umzudrehen ist der häufigste teure Fehler bei AR-Projekten: eine vollständige native App für eine einmalige Marketingkampagne zu bauen, die null Reibung gebraucht hätte, oder eine Browser-Demo für ein Feature zu entwickeln, das dauerhaft bestehen und sich in eine App integrieren musste, die Menschen bereits täglich nutzen.
Was es kostet
Ein Casual-Mobile-Game oder eine gebrandete AR-Erfahrung – ob WebXR oder nativ – beginnt in der Regel bei etwa $15,000. Multiplayer-3D-Titel und vollständige VR-Builds, mit zusätzlichem Engineering-Aufwand für Netcode, Physik und headset-spezifische Optimierung, starten ab $50,000+.
Fazit
Der Standardgedanke sollte nicht „Wir bauen eine App“ sein. Fragen Sie stattdessen zuerst, wie jemand die Erfahrung tatsächlich erreicht, und lassen Sie diese Antwort die Plattform bestimmen. Unser Team für Games, AR & VR legt Engine und Auslieferungsweg – WebXR, native Mobile-App oder ein Vision-Pro/Quest-Build – danach fest, wie Ihre konkrete Zielgruppe die Erfahrung tatsächlich erleben wird, nicht danach, welche Plattform im Pitch-Deck beeindruckender klingt.
