USDZ nach der WWDC26: Vom Maschinenraum auf die Bühne

USDZ hat dieses Jahr den Job gewechselt. Apple baut intern nicht mehr in USDZ und zur Laufzeit liefert RealityKit nicht mehr in USDZ. Trotzdem steht USDZ nach der WWDC26 besser da als vorher. Klingt widersprüchlich — ist es aber nicht.

Ich schaue auf USDZ aus der Vertriebsperspektive, nicht aus der Engine-Sicht. Bei uns reist ein Produktmodell von der Konstruktion über die Agentur auf die Messe bis zum Kunden. USDZ ist dabei der Umschlag, in dem das Modell ankommt. Für diesen Umschlag ändert die WWDC26 drei Dinge.

1. Reality Composer Pro baut nicht mehr in USDZ

RCP3 ist eine eigenständige App geworden und speichert Projekte intern als JSON, nicht als USD. Beim Import wandert eine USDZ-Datei in ein optimiertes Bundle, das Laufzeitformat heißt jetzt .reality.

→ Übersicht: USD, USDZ, USDA, USDC & Reality

Für USDZ heißt das: Im RealityKit-Werkzeugkasten ist es weder Editier- noch Laufzeitformat. Das ist für mich die eigentliche Nachricht: Wer USDZ je als Arbeitsdatei behandelt hat — drin editieren, hinten verlustfrei wieder rauslesen — kann das abhaken.

2. Safari macht USDZ zum Web-Format

Der Gegenzug: Safari bekommt das <model>-Tag. Ein USDZ liegt damit im HTML wie ein Bild, nur räumlich. Auf der Vision Pro bricht das Modell aus der Seite heraus — ohne App, ohne Store, ohne Umweg.

AR Quick Look bleibt, das offene Web kommt dazu. Auf diesen Moment warte ich seit Jahren: Unser Web-USDZ-Pfad — Modell im Browser, kein App-Zwang — steht nicht mehr auf einem Apple-Sonderweg, sondern auf einem Tag.

3. Kompression macht USDZ web-tauglich

Dazu ein neuer Mesh-Codec plus AVIF für Texturen. (Haben wir tatsächlich schon in diversen Projekten umgesetzt, als es noch keine Tools von Apple gab: Fallbeispiel zgoll-Raumkonfigurator & Projektbericht) Apple nennt im Schnitt siebenfach kleinere Dateien, und das Werkzeug dafür (usdcrush) fließt zurück in OpenUSD. Ein Maschinenmodell, das vorher 80 Megabyte wog, landet bei rund zehn. Das ist der Unterschied zwischen „lädt am Messestand” und „lädt nicht”.

Mein Take

USDZ wandert von der Quelle der Wahrheit zum Liefercontainer — und das ist die richtige Richtung. Ein Format kann nicht gleichzeitig die beste Arbeitsdatei und der beste Versandweg sein.

Apple trennt diese zwei Rollen endlich sauber: Bauen und Versionieren übernimmt der USD-Layer, programmatisch jetzt über USDKit. Ausgeliefert wird über USDZ.

Für uns im Vertrieb ist das die bessere Welt. Wir verkaufen zwar auch Pipelines an einige Kunden — für die meisten verkaufen wir jedoch Verständlichkeit. Ein Kunde, der ein Modell ohne Installation im Browser dreht, fragt nicht nach dem Dateiformat. Er fragt nach dem Nutzen und Preis.

Praktisch heißt das: An euren USDZ-Dateien für Quick Look und AR ändert sich nichts — die laufen weiter. Neu ist der Weg ins offene Web. Ein Konfigurator-Modell, ein Messe-Exponat, ein 3D-Hero auf der Landingpage — das geht jetzt noch besser ohne native App, mit einem <model>-Tag und einer Datei, die klein genug fürs Mobilnetz am Messestand ist. Wer bisher auf eine eigene glTF-WebAR-Lösung gesetzt hat, sollte den nativen Pfad neu rechnen.

Die Kehrseite gehört dazu: Wer seine Quelle der Wahrheit in USDZ-Dateien hält, muss umbauen. Die Wahrheit gehört in den USD-Layer, nicht in den Versandkarton. Wer das trennt, gewinnt. Wer es vermischt, hat jetzt Arbeit.

Demnächst: das Engineering-Gegenstück

So weit mein Blick — der eines Menschen, der USDZ benutzt, nicht baut. Die andere Hälfte liefert mein Kollege Thomas Kumlehn. Thomas sitzt alle zwei Wochen in den USDWG-Calls und schaut auf dieselbe WWDC26 mit Ingenieursaugen. In den nächsten Tagen nehmen wir dazu einen Podcast auf: zwei Perspektiven auf denselben Bruch — Vertrieb trifft Engineering. Seine Sicht auf USDKit, .reality und die Frage, was das offene USD-Versprechen wirklich wert ist, hört ihr dann hier.