Unity hat einen eigenen External Dependency Manager für native Android- und iOS-Bibliotheken vorgestellt. Das kostenlose Paket basiert auf Googles External Dependency Manager for Unity, kurz EDM4U, und wird über den Unity Package Manager verteilt. Unterstützt werden Unity 2022.3 und neuere Versionen.
Solche Resolver werden benötigt, wenn ein Unity-SDK zusätzliche native Bibliotheken einbindet, etwa für Anmeldung, Werbung oder Zahlungsdienste. Die C#-Dateien im Projekt allein bilden diese Abhängigkeiten nicht ab. Der neue Manager verarbeitet bestehende XML-Beschreibungen und unterstützt Gradle sowie auf iOS CocoaPods und Swift Package Manager.
Wechsel nicht durch vorschnelles Deinstallieren erzwingen
Laut Unity soll Googles bisheriges Paket am 26. Oktober 2026 als veraltet gekennzeichnet werden. Die Einrichtungsanleitung für den External Dependency Manager beschreibt den parallelen Bestand beider Pakete: Im Projekt wird ausgewählt, welcher Manager aktiv arbeitet. Das bisherige EDM4U sollte nicht entfernt werden, solange andere installierte SDKs es noch als Abhängigkeit voraussetzen. Andernfalls können abhängige Pakete ebenfalls entfernt werden.
Die Release Notes zu EDM 2.1.0 vom 14. September 2026 nennen Einstellungen für Swift-Package-Manager-Ziele und überarbeitete Bedienoberflächen. Hinzu kommen Verbesserungen bei der Erkennung und Installation von CocoaPods und Ruby. Ein fehlendes Verzeichnis Assets/Plugins/Android wird automatisch angelegt, damit die Android-Auflösung daran nicht scheitert. Die konkrete Paketversion sollte bei der Migration festgehalten werden.
Reproduzierbare Builds bleiben eine Projektaufgabe
Für automatisierte Mobile-Builds betrifft die Änderung eine andere Ebene als die Unity CLI für Tests und Build-Pipelines: Die CLI startet und steuert Editor-Aufgaben, der Dependency Manager bereitet native Bibliotheken vor. Beide Schritte müssen auf einer frischen Build-Maschine funktionieren. Ein erfolgreicher lokaler Export ersetzt diesen Test nicht.
Praktisch empfiehlt sich eine Migration in einem separaten Entwicklungszweig mit je einem Android- und iOS-Testbuild, soweit beide Plattformen unterstützt werden. Dabei sind Paketversionen und Resolver-Ausgaben zu vergleichen. So lässt sich ein Fehler bei der Bibliotheksauflösung von einem Fehler im eigentlichen Spielcode unterscheiden.