hdiutil ist in macOS 27 veraltet. Der Nachfolger ist schon da.

macOSTahoe ·
hdiutil ist in macOS 27 veraltet. Der Nachfolger ist schon da.

Apple hat hdiutil in macOS 27 zugunsten von diskutil image als veraltet markiert. Dieser Befehl ist schon heute auf Ihrem Mac vorhanden – und ihm fehlen Dinge, die Sie vermutlich nutzen.

Die Man-Page in macOS 27 Golden Gate enthält eine Zeile, die es dort noch nie gab:

In macOS 27.0 ist hdiutil veraltet. Verwenden Sie stattdessen diskutil image für alle Disk-Image-Operationen.

hdiutil ist seit Mac OS X 10.0 der Weg, um auf dem Mac Disk-Images zu erstellen, einzubinden, zu konvertieren und zu untersuchen. Wenn Sie jemals eine .dmg ausgeliefert, ein Installationsskript geschrieben, einen CI-Job zum Packen einer Mac-App gebaut oder einen verschlüsselten Container zum Schutz privater Daten angelegt haben, haben Sie es verwendet – direkt oder über ein Werkzeug, das es für Sie aufgerufen hat.

Hier ist der Teil, den die meisten Berichte übersehen haben: Der Nachfolger kommt nicht erst noch. Er ist bereits auf Ihrem Mac. Öffnen Sie jetzt sofort das Terminal unter macOS 26 Tahoe und führen Sie diskutil image aus. Der Befehl antwortet.

Die wichtigsten Erkenntnisse

  • diskutil image funktioniert bereits unter macOS 26. Verifiziert unter macOS 26.5.2 (Build 25F84). Sie können Skripte schon heute migrieren und testen, noch bevor macOS 27 erscheint.
  • Veraltet heißt nicht entfernt. hdiutil funktioniert in macOS 27 weiterhin. Am ersten Tag bricht nichts. Aber Apple beschneidet das Werkzeug bereits seit sieben Jahren, und die Man-Page dokumentiert jeden einzelnen Schritt.
  • Der Befehlsumfang ist deutlich kleiner. hdiutil bietet 23 Verben. diskutil image bietet 5 Unterbefehle.
  • Es gibt kein detach. Mit diskutil image können Sie ein Disk-Image einbinden, aber nicht wieder aushängen – das wandert zu diskutil eject.
  • Für manche Funktionen gibt es schlicht noch keinen Ersatz, darunter verify, compact und makehybrid. Wenn Ihre Build-Skripte diese verwenden, existiert heute kein Migrationspfad.

Zuerst: Selbst auf dem eigenen Mac nachprüfen

Verlassen Sie sich bei alldem nicht auf mein Wort. Ein einziger Befehl genügt:

diskutil image

Unter macOS 26.5.2 gibt das Folgendes aus:

OVERVIEW: Manipulate disk images (attach, create, etc)

USAGE: diskutil image [--verbose] [--stdinpassphrase] [--plist] <subcommand>

SUBCOMMANDS:
  attach                  Attach a disk image as a device.
  info                    Print info regarding a disk image.
  create                  Create a disk image. Either blank or from an existing
                          source (disk, disk image or folder).
  resize                  Resize a given image to a specified size if
                          applicable.
  chpass                  Change the passphrase of a given encrypted image.

Fünf Unterbefehle. Vergleichen Sie das nun mit dem, was hdiutil bietet – direkt aus dessen eigener Man-Page:

Common verbs include attach, detach, verify, create, convert, and compact.

The rest of the verbs are currently: help, info, burn, checksum, chpass,
erasekeys, imageinfo, isencrypted, mountvol, unmount, plugins, udifrez,
udifderez, resize, segment, makehybrid, and pmap.

Das sind 23 Verben gegenüber 5 Unterbefehlen. Dieses Verhältnis wirkt auf den ersten Blick alarmierend und ist zugleich irreführend, denn ein reiner Verb-für-Verb-Vergleich führt zum falschen Ergebnis. Mehrere hdiutil-Verben stecken unter anderem Namen in diskutil image, mehrere waren schon vor Jahren als veraltet markiert, und eines der wichtigen ist komplett zu einem anderen Befehl gewandert.

Herauszufinden, was wohin gehört, ist die eigentliche Migration – machen wir das also gründlich.

Das kam nicht aus dem Nichts

Vor der Migrationstabelle noch etwas Kontext, der die Veralterung weniger abrupt erscheinen lässt. Die Man-Page von hdiutil enthält einen Kompatibilitätsabschnitt, der sich wie ein sieben Jahre langes Protokoll liest, in dem Apple das Werkzeug Schritt für Schritt beschneidet. Das steht schon jetzt auf Ihrem Mac – man hdiutil öffnen und nach den Versionsüberschriften suchen:

macOS 10.15

  • Führte die lzma-Komprimierung im ULMO-Format ein
  • Markierte die Unterstützung für Dual-Fork-Dateien im OS-9-Stil als veraltet (hdiutil flatten/unflatten)
  • Entfernte den veralteten Befehl hdiutil internet-enable sowie die IDME-Attach-Flags

macOS 11.0

  • Entfernte die Unterstützung für die Formate DiskCopy42, DART und NDIF
  • Entfernte die Unterstützung für die Kodierungen AppleSingle und MacBinary
  • Entfernte die Dual-Fork-Dateiunterstützung im OS-9-Stil
  • Änderte das Standarddateisystem für neue Images auf APFS

macOS 12.0

  • Markierte das UDBZ-Format (bzip2-Komprimierung) als veraltet
  • Markierte segmentierte UDIF-Images als veraltet (hdiutil segment, -segmentSize)
  • Markierte hdiutil udifrez/udifderez als veraltet (Ressourcen einbetten und extrahieren)

macOS 13.0

  • Entfernte die Option encrypted-encoding-version; alle neuen verschlüsselten Images verwenden Version 2

Die Man-Page weist zudem direkt im Text darauf hin, dass -passphrase unsicher ist, dass segmentierte Images veraltet sind und dass UDBZ veraltet ist.

Als Ganzes gelesen ist die Veralterung in macOS 27 der letzte Schritt eines Prozesses, der etwa 2019 begonnen hat, und keine Entscheidung, die diesen Sommer gefallen ist. Das ist für die Planung wichtig: Apple entfernt Funktionen aus diesem Werkzeug langsam und kündigt sie zuerst in der Man-Page an. hdiutil ist in macOS 27 veraltet, nicht verschwunden, und es gibt kein angekündigtes Entfernungsdatum.

Die Migrationstabelle

Das ist die Übersicht. Ich habe jeden dieser Punkte unter macOS 26.5.2 getestet.

Was Sie erreichen wollenhdiutildiskutil image
Ein Image einbindenhdiutil attach x.dmgdiskutil image attach x.dmg
Ein Image aushängenhdiutil detach /dev/diskNNicht in diskutil image — stattdessen diskutil eject /dev/diskN verwenden
Ein leeres Image erstellenhdiutil create -size 1g -fs APFS x.dmgdiskutil image create blank --size 1g x.dmg
Ein Image aus einem Ordner erstellenhdiutil create -srcfolder ./dir x.dmgdiskutil image create from ./dir x.dmg
Format konvertierenhdiutil convert in.dmg -format UDZO -o out.dmgdiskutil image create from in.dmg out.dmg --format UDZO
Ein Image untersuchenhdiutil imageinfo x.dmgdiskutil image info x.dmg
Prüfen, ob verschlüsselthdiutil isencrypted x.dmgdiskutil image info → Is Encrypted:
Größe ändernhdiutil resize -size 2g x.dmgdiskutil image resize
Passphrase ändernhdiutil chpass x.dmgdiskutil image chpass x.dmg
Prüfsumme verifizierenhdiutil verify x.dmgKeine Entsprechung
Ein Sparse-Image komprimierenhdiutil compact x.sparsebundleKeine Entsprechung
Ein Hybrid-/ISO-Image erstellenhdiutil makehybridKeine Entsprechung
Eine Lizenzvereinbarung einbettenhdiutil udifrezKeine Entsprechung (seit macOS 12 veraltet)
Auf optische Medien brennenhdiutil burnKeine Entsprechung

Die Überraschung bei convert

Der häufigste Fehler, den ich in den ersten Kommentaren gesehen habe, lautet: „Es gibt kein convert." Doch, das gibt es – es heißt nur anders.

OVERVIEW: Create a disk image from an existing source (disk, disk image or
folder).

Source and destination disk image can be the same, which will perform the
conversion in place.

diskutil image create from akzeptiert ein Disk-Image als Quelle, ist also hdiutil convert unter anderem Namen – und unterstützt zusätzlich die Konvertierung an Ort und Stelle, was hdiutil convert nie konnte. Wer nur Verben zählt, statt den Hilfetext zu lesen, kommt zu dem Schluss, eine Funktion sei weggefallen, obwohl sie tatsächlich erweitert wurde.

Die Lücke bei detach ist real

Das ist keine bloße Umbenennung. Es gibt in diskutil image nirgendwo ein detach:

$ diskutil image detach /dev/disk12
Error: 2 unexpected arguments: 'detach', '/dev/disk12'
Usage: diskutil image [--verbose] [--stdinpassphrase] [--plist] <subcommand>

Der Ersatz ist der übergeordnete Befehl diskutil:

$ diskutil eject /dev/disk12
Disk /dev/disk12 ejected

Das funktioniert einwandfrei – aber beachten Sie, was das für ein Skript bedeutet. Aus der sauberen Symmetrie von hdiutil attach / hdiutil detach wird diskutil image attach / diskutil eject, zwei unterschiedliche Unterbefehlsebenen desselben Binarys. Jede Wrapper-Funktion, die attach und detach paart, muss umstrukturiert werden – ein simples Suchen-und-Ersetzen reicht nicht.

Skripte für Disk-Images migrieren

Was diskutil image besser macht

Es wäre unfair, das Ganze als reinen Verlust darzustellen. Drei Dinge sind tatsächlich besser geworden.

ASIF, das hdiutil gar nicht erst erstellen kann

diskutil image unterstützt das Apple Sparse Image Format. hdiutil nicht. Wer ASIF will – und für virtuelle Festplatten auf APFS ist das genau das Format, auf das Apple hinsteuert – kommt nur mit diskutil image ans Ziel.

Die Formatlisten lohnen einen Blick:

create blank --format : RAW, ASIF, UDSB          (default RAW)
create from  --format : ASIF, RAW, UDRO, UDSB,
                        UDZO, ULFO, ULMO         (default ULFO)

Es bindet über HTTP ein und erstellt RAM-Disks direkt

Aus der Hilfe zu attach:

Supports 'ram://<size>', file paths, http[s].

Eine RAM-Disk unter macOS zu erstellen war traditionell der umständliche Zweischritt hdiutil attach -nomount ram://<sectors> gefolgt von newfs_hfs oder diskutil eraseVolume. Hier reicht ein Argument zu einem dokumentierten Flag.

Es ist deutlich schneller

Jeff Johnson von Lapcat Software hat beide Werkzeuge Anfang August 2026 im Rahmen seiner Untersuchung der Veralterung im Benchmark verglichen und gemessen, dass diskutil image eine create-Operation in 40–45 Sekunden abschließt, gegenüber 110–115 Sekunden bei hdiutil – und dabei noch ein kleineres Image produziert. Das ist kein Rundungsfehler. Für einen CI-Job, der bei jedem Commit Disk-Images baut, macht das einen spürbaren Unterschied.

Was in Ihren Skripten tatsächlich kaputtgeht

Veraltungswarnungen bringen Builds nicht zum Scheitern. Diese Dinge hier schon.

1. Für -puppetstrings gibt es keinen Ersatz

Das Flag -puppetstrings von hdiutil liefert maschinenlesbare Fortschrittsausgaben – genau das, was ein Build-System braucht. Johnson nennt dessen Fehlen als eine der bemerkenswerten Lücken. diskutil image bietet --plist für strukturierte Ergebnisse, gibt den Fortschritt aber nur menschenlesbar aus, etwa so:

[5% completed] [79% completed] [98% completed] [100% completed]
test.dmg created

Wenn Ihr Tooling PERCENT:-Zeilen von hdiutil parst, hat dieser Parser nichts mehr, woran er ansetzen kann.

2. Mehrere create-Optionen sind schlicht verschwunden

Johnsons Bericht listet -[no]crossdev, -[no]scrub, -[no]anyowners, -skipunreadable, -[no]atomic und -copyuid als ohne Entsprechung auf. Wenn Sie Images kontrolliert aus Ordnern bauen – Installer, forensische Erfassungen, alles, bei dem Besitzrechte oder die genau enthaltenen Dateien exakt stimmen müssen –, lesen Sie diese Liste sorgfältig durch. Besonders -skipunreadable und -copyuid sind für manche Packaging-Skripte unverzichtbar.

3. Das Scrubbing-Verhalten hat sich stillschweigend geändert

Johnson berichtet, dass diskutil image temporäre Dateien wie Papierkorb-Ordner automatisch ausschließt und sich damit verhält, als wäre -scrub immer aktiv. hdiutil hat nur auf ausdrückliche Anweisung gescrubbt. Wenn der Inhalt Ihres Images byte-identisch zu einem Quellverzeichnis sein soll, entsteht hier ohne Vorwarnung ein anderes Image.

4. Die Rechteverwaltung schlägt stillschweigend fehl

Das würde ich als Erstes testen. Johnson hat festgestellt, dass diskutil image an der Stelle, an der hdiutil bei root-eigenen Dateien einen Authentifizierungsdialog auslöst, keine Nachfrage stellt, sondern schlicht fehlschlägt. Ein Skript, das früher auf Zugangsdaten wartete, erzeugt nun ein unvollständiges Image und meldet je nach Fehlerbehandlung womöglich trotzdem Erfolg.

Wenn Sie Images aus Verzeichnissen bauen, die Dateien enthalten, die Ihnen nicht gehören, prüfen Sie das Ergebnis, statt dem Exit-Code zu vertrauen.

5. Das Logging ist dünner

Die ausführliche Ausgabe von diskutil image ist weniger detailliert als die von hdiutil. Wenn ein Build um drei Uhr morgens fehlschlägt, merken Sie genau das.

Migrieren, ohne die Unterstützung für macOS 26 zu verlieren

Die meisten von uns müssen eine Weile beide Varianten unterstützen. Die gute Nachricht – und der eigentliche praktische Kern dieses Artikels – ist, dass Sie nicht nach OS-Version verzweigen müssen, weil diskutil image auch unter macOS 26 existiert.

Prüfen Sie die Fähigkeit, nicht die Version:

#!/bin/bash
# Prefer diskutil image; fall back to hdiutil where unavailable.

if diskutil image --help >/dev/null 2>&1; then
  USE_DISKUTIL=1
else
  USE_DISKUTIL=0
fi

make_image_from_folder() {
  local src="$1" dst="$2"
  if [ "$USE_DISKUTIL" -eq 1 ]; then
    diskutil image create from "$src" "$dst" --format UDZO
  else
    hdiutil create -srcfolder "$src" -format UDZO "$dst"
  fi
}

attach_image() {
  local img="$1"
  if [ "$USE_DISKUTIL" -eq 1 ]; then
    diskutil image attach "$img" --nobrowse
  else
    hdiutil attach "$img" -nobrowse
  fi
}

detach_device() {
  # Note the asymmetry: detach is NOT under `diskutil image`.
  local dev="$1"
  if [ "$USE_DISKUTIL" -eq 1 ]; then
    diskutil eject "$dev"
  else
    hdiutil detach "$dev"
  fi
}

Prüfen Sie anschließend das Ergebnis, denn genau dort verstecken sich die stillen Unterschiede:

# Compare what actually landed in the image against the source.
diskutil image attach build.dmg --nobrowse --mountPoint /tmp/verify_mnt
diff -rq ./src /tmp/verify_mnt/src
diskutil eject /tmp/verify_mnt

Dieses diff -rq ist der Schritt, den ich nicht auslassen würde. Zwischen dem permanent aktiven Scrubbing und den stillen Rechteproblemen ist ein erfolgreich gebautes Image nicht dasselbe wie ein Image, das das enthält, was Sie eigentlich wollten.

Wenn Sie eine Mac-Entwicklungsumgebung von Grund auf aufbauen, behandelt unser Leitfaden zur Einrichtung einer Apple-Silicon-Entwicklungsumgebung das umgebende Tooling, und der Leitfaden zur Terminal-Beherrschung behandelt die Shell-Grundlagen, die diese Skripte voraussetzen.

Inhalt von Disk-Images verifizieren

Ein durchgerechnetes Beispiel von Anfang bis Ende

Hier ist ein vollständiger Durchlauf unter macOS 26.5.2, damit Sie die echte Ausgabe sehen und nicht nur eine Rekonstruktion.

Ein Image aus einem Ordner erstellen:

$ mkdir -p src && echo "hello" > src/file.txt
$ diskutil image create from src --format UDZO test.dmg
[5% completed] [79% completed] [98% completed] [99% completed] [100% completed]
test.dmg created

Untersuchen:

$ diskutil image info test.dmg
Image Format: UDZO
Format Description: UDIF read-only compressed image (zlib)

	Identity Info:
		UUID: 061189CB-7502-4EA6-BFE3-424442C16D10

	Size Info:
		Empty Bytes: 3437056
		Total Bytes: 4233216

	Compression Info:
		Compressed Bytes: 4124
		Compression Type: zlib

	Encryption Info:
		Is Encrypted: 0

	Master Checksum Info:
		Checksum Type: crc32
		Checksum Value: c4 e3 90 4b

Beachten Sie, dass info das abdeckt, was früher hdiutil imageinfo, isencrypted und Teile von checksum getrennt geliefert haben. Es meldet die gespeicherte Prüfsumme – es verifiziert sie nicht. Das ist die Lücke bei hdiutil verify.

Einbinden:

$ diskutil image attach test.dmg
/dev/disk12  	GUID_partition_scheme
/dev/disk13s1	Apple_APFS_Volume    	/Volumes/src

Aushängen – mit dem anderen Befehl:

$ diskutil eject /dev/disk12
Disk /dev/disk12 ejected

Verschlüsselte Images

Wenn Sie Disk-Images als verschlüsselte Container nutzen, ist die Mechanik unkompliziert, aber die Optionen sind eingeschränkter.

# Create an encrypted blank image
diskutil image create blank --encrypt --size 10g --volumeName Vault vault.dmg

# Provide the passphrase on stdin rather than interactively
printf '%s' "$PASSPHRASE" | diskutil image create blank --encrypt --stdinpassphrase \
  --size 10g --volumeName Vault vault.dmg

# Change the passphrase later
diskutil image chpass vault.dmg

--encrypt ist als AES-256 dokumentiert, eine Wahl des Algorithmus gibt es nicht – das ist eher eine Vereinfachung als ein Verlust, denn die ältere verschlüsselte Encoding-Version hat Apple bereits in macOS 13 entfernt.

Das Flag --stdinpassphrase ist dasjenige, das Sie in jedem Skript verwenden sollten. Schon die eigene Man-Page von hdiutil warnt, dass -passphrase unsicher ist – aus dem simplen Grund, dass eine Passphrase auf der Kommandozeile in der Prozesstabelle für jeden Benutzer der Maschine sichtbar ist.

Wenn Sie sich bei Disk-Images auf Datenschutz statt auf reinen Komfort verlassen, lohnt sich ein Blick in unseren Leitfaden zu Mac-Sicherheit und Datenschutz, um einzuordnen, wo ein verschlüsseltes Image im Verhältnis zu FileVault steht – beide lösen unterschiedliche Probleme, und eine verschlüsselte .dmg schützt nichts, solange sie eingebunden ist.

Wofür Disk-Images noch immer gebraucht werden

Es lohnt sich zu fragen, warum das überhaupt wichtig ist, denn „Disk-Image" klingt nach einem Relikt, während das dazugehörige Tooling an mehreren Stellen still und leise tragend ist.

App-Distribution. Die .dmg bleibt der Standardweg, um eine Mac-App außerhalb des App Store auszuliefern. Ein komprimiertes, schreibgeschütztes Image mit einem App-Bundle und einem Symlink zu /Applications ist die aus Drag-and-drop-Installation bekannte Konvention. Jedes davon wird von einem Skript gebaut, das ein Disk-Image-Werkzeug aufruft.

Verschlüsselte Container. Eine verschlüsselte .dmg ist ein portabler, in sich geschlossener Tresor, der sich als Volume einbinden lässt und auf jedem Mac ohne Spezialsoftware funktioniert. Anders als FileVault, das eine ganze Festplatte im Ruhezustand schützt, schützt ein verschlüsseltes Image eine bestimmte Dateimenge, die Sie frei bewegen können – auf einen USB-Stick, in einen Cloud-Speicher, zu einem Kollegen.

Festplatten für virtuelle Maschinen. Hier spielt ASIF seine Stärken aus, und hier wird Apples Richtung deutlich.

Sparsebundles für Netzwerk-Backups. Sichert Time Machine auf ein Netzwerkziel, landet das Backup in einem Sparsebundle – einem Disk-Image, das in viele kleine Band-Dateien aufgeteilt ist, sodass nur geänderte Bands synchronisiert werden müssen. Wer schon einmal so eines gepflegt hat, hat hdiutil compact ausgeführt, um Speicherplatz von gelöschten Bands zurückzugewinnen.

Forensik und Archivierung. Ein blockbasiertes Image eines Volumes mit Prüfsumme ist die Art und Weise, wie man den exakten Zustand einer Festplatte bewahrt. hdiutil verify ist die Art und Weise, wie man das später bestätigt.

Hält man diese Liste gegen die Migrationstabelle, fallen die Lücken nicht zufällig, sondern genau bei bestimmten Nutzergruppen. App-Entwickler verlieren den Lizenzvereinbarungs-Mechanismus und -puppetstrings. Nutzer von Backups und Sparsebundles verlieren compact. Nutzer aus Archivierung und Forensik verlieren verify. Wer nur die üblichen create-convert-attach-Arbeiten erledigt, ist unbetroffen.

ASIF: Das Format, das nur das neue Werkzeug erstellt

Das Apple Sparse Image Format ist das deutlichste Signal dafür, warum Apple die Nutzer von hdiutil weglocken will – denn hdiutil kann es überhaupt nicht erzeugen.

Ein Sparse-Image belegt nur für Blöcke, die tatsächlich Daten enthalten, Speicherplatz. Ein 100-GB-Sparse-Image mit 10 GB an Dateien belegt auf der Festplatte etwa 10 GB und wächst, wenn Daten hinzukommen. Das alte Sparse-Image-Format UDSP und das Sparsebundle-Format UDSB machten das ebenfalls, mit bekannten Problemen: Sparsebundles fragmentieren in Tausende Band-Dateien, und beide Formate gaben historisch nur schlecht Speicherplatz frei – genau deshalb musste hdiutil compact existieren.

ASIF ist gegen APFS entworfen, statt nur oben draufgesetzt zu werden, sodass die eigene Sparse-File-Unterstützung des Dateisystems die Arbeit übernimmt, anstatt dass das Image-Format sie nachbildet. In der Praxis zeigt sich der Vorteil am deutlichsten bei der Virtualisierung, wo die virtuelle Festplatte einer VM eine große, größtenteils leere Datei ist, die sich ständig ändert – genau der Fall, der die alten Formate am härtesten bestraft hat.

Sie können schon heute eines erstellen:

# A 100GB ASIF image that occupies only what it uses
diskutil image create blank --format ASIF --size 100g \
  --volumeName VMDisk vmdisk.asif

# Convert an existing image to ASIF
diskutil image create from old.dmg new.asif --format ASIF

Beachten Sie, dass das Format aus der Dateiendung abgeleitet wird – create blank verwendet standardmäßig RAW, „sofern der Image-Pfad nicht die Endung .asif oder .sparsebundle hat". Die Datei richtig zu benennen genügt; --format zusätzlich anzugeben ist Gürtel und Hosenträger.

Der Kompromiss ist die Portabilität. ASIF ist neu, und ein ASIF-Image lässt sich weder auf einem älteren macOS noch auf etwas, das kein Mac ist, öffnen. Für eine VM-Festplatte oder ein lokales Arbeitsvolume ist das irrelevant. Für alles, was Sie an eine andere Person weitergeben, nutzen Sie UDZO und behalten die Kompatibilität.

Wo das in eine Distributions-Pipeline passt

Wenn Sie eine Mac-App außerhalb des App Store ausliefern, sitzt der Disk-Image-Schritt mitten in einer Kette – und es lohnt sich zu sehen, wo die Änderung landet.

#!/bin/bash
set -euo pipefail

APP="build/MyApp.app"
DMG="dist/MyApp.dmg"
STAGE="$(mktemp -d)"

# 1. Sign the app bundle (unchanged by any of this)
codesign --force --options runtime --timestamp \
  --sign "Developer ID Application: Example Inc (TEAMID123)" \
  "$APP"

# 2. Stage the contents the user will see
cp -R "$APP" "$STAGE/"
ln -s /Applications "$STAGE/Applications"

# 3. Build the image — the step this article is about
diskutil image create from "$STAGE" "$DMG" --format UDZO

# 4. Sign the image itself
codesign --force --timestamp \
  --sign "Developer ID Application: Example Inc (TEAMID123)" \
  "$DMG"

# 5. Notarize and staple
xcrun notarytool submit "$DMG" --keychain-profile "AC_NOTARY" --wait
xcrun stapler staple "$DMG"

rm -rf "$STAGE"

Nur Schritt 3 ändert sich. Signierung, Notarisierung und Stapling sind unbetroffen – sie arbeiten mit dem fertigen Image, und es ist ihnen egal, welches Werkzeug es erzeugt hat.

Zwei Dinge sind in einer echten Pipeline zu beachten. Erstens: Prüfen Sie, ob der bereitgestellte Inhalt korrekt gelandet ist – wegen des oben beschriebenen stillen Scrubbings und Rechteverhaltens ist ein diff -rq zwischen $STAGE und dem eingebundenen Ergebnis eine billige Versicherung. Zweitens: Bettet Ihr aktuelles Skript eine Lizenzvereinbarung mit hdiutil udifrez ein, hat dieser Schritt keinen Ersatz und ist bereits seit macOS 12 veraltet. Behalten Sie hdiutil dafür, solange es existiert, und planen Sie eine Alternative.

Häufige Probleme beheben

„diskutil image: command not found" oder der Unterbefehl wird nicht erkannt

Problem: Sie befinden sich auf einer macOS-Version älter als 26, auf der es das Verb image nicht gibt.

Lösung: Verwenden Sie die oben gezeigte Fähigkeitsprüfung, statt etwas anzunehmen. diskutil image --help >/dev/null 2>&1 liefert auf Systemen ohne diese Funktion einen Wert ungleich null – das ist eine verlässliche Verzweigung. Testen Sie nicht sw_vers – ob der Unterbefehl vorhanden ist, ist das, was Sie tatsächlich interessiert.

Das Image wird gebaut, aber es fehlen Dateien

Problem: Zwei wahrscheinliche Ursachen. Entweder hat diskutil image Dateien übersprungen, die es mit Ihrem Benutzer nicht lesen konnte, und nicht nach einer Authentifizierung gefragt, oder das permanent aktive Scrubbing hat Elemente entfernt, die hdiutil mit aufgenommen hätte.

Lösung: Binden Sie das Ergebnis ein und führen Sie ein diff -rq gegen das Quellverzeichnis aus. Fehlen Dateien wegen der Besitzrechte, führen Sie den Build mit den nötigen Rechten aus, statt auf eine Abfrage zu warten. Verlassen Sie sich nicht allein auf den Exit-Code.

Das Parsen des Fortschritts ist in der CI kaputtgegangen

Problem: Für -puppetstrings gibt es kein Äquivalent in diskutil image, sodass Skripte, die die maschinenlesbaren Fortschrittsangaben von hdiutil geparst haben, nichts mehr zu lesen haben.

Lösung: Verwenden Sie --plist für das strukturierte Ergebnis und behandeln Sie den Fortschritt als nicht verfügbar. Wenn Ihre CI konkret Fortschrittsdaten benötigt, ist es legitim, hdiutil für diesen Schritt zu behalten – es ist veraltet, nicht entfernt, und es gibt kein angekündigtes Entfernungsdatum.

Aushängen nicht möglich – „resource busy"

Problem: Irgendetwas hat das Volume noch geöffnet. Das verhält sich genauso wie schon immer.

Lösung: lsof +D /Volumes/IhrVolume, um den Verursacher zu finden, dann diskutil eject. Spotlight-Indizierung und Antivirus-Scanner sind häufige Übeltäter; das Einbinden mit --nobrowse umgeht einen Teil davon, indem das Volume aus dem Finder herausgehalten wird.

Eine .dmg mit Lizenzvereinbarung lässt sich nicht mehr bauen

Problem: Der Lizenzvereinbarungs-Mechanismus stützt sich auf hdiutil udifrez, das Apple bereits in macOS 12 als veraltet markiert hat und für das es in diskutil image keine Entsprechung gibt.

Lösung: Es gibt keinen Ersatzpfad. Verwenden Sie für diesen Schritt weiter hdiutil, solange es existiert, und planen Sie eine Distributionsmethode, die nicht auf einer eingebetteten Vereinbarung beruht. Das ist bereits seit vier Jahren absehbar – gut zu wissen, falls Sie es erst jetzt entdecken.

Häufig gestellte Fragen

Funktioniert hdiutil in macOS 27 noch?

Ja. Es ist veraltet, nicht entfernt. Veralterung ist Apples Art, Absicht zu signalisieren und eine Frist laufen zu lassen – keine funktionale Änderung. Nichts, was heute funktioniert, hört auf zu funktionieren, sobald Sie macOS 27 installieren.

Wann wird hdiutil tatsächlich entfernt?

Apple hat sich dazu nicht geäußert. Blickt man auf die eigene Historie der Man-Page, hat Apple mit diesem Werkzeug das Muster, eine Funktion in einem Release als veraltet zu markieren und sie erst eine oder mehrere Hauptversionen später zu entfernen – internet-enable und die OS-9-Dual-Fork-Unterstützung brauchten jeweils mindestens einen vollen Zyklus. Wer Ihnen eine konkrete Version für die Entfernung nennt, rät.

Kann ich diskutil image unter macOS 26 Tahoe nutzen?

Ja, und das ist die nützlichste Tatsache in diesem Artikel. Verifiziert unter macOS 26.5.2 (Build 25F84). Sie können Skripte jetzt migrieren und testen, auf dem OS, das Sie bereits nutzen, statt auf macOS 27 zu warten.

Ist diskutil image ein vollständiger Ersatz für hdiutil?

Nein, heute noch nicht. Für verify, compact, makehybrid und burn gibt es keine Entsprechung, und mehrere create-Optionen zur genauen Steuerung, welche Dateien aufgenommen werden, fehlen. Für den üblichen Weg – erstellen, konvertieren, einbinden, untersuchen, Größe ändern, verschlüsseln – ist es vollständig.

Warum hat Apple das gemacht?

Apple hat dazu keine Begründung veröffentlicht. Beobachtbar ist, dass diskutil image in Benchmarks schneller ist, kleinere Images erzeugt, das neuere ASIF-Format unterstützt, das hdiutil nicht erzeugen kann, und eine deutlich kleinere Befehlsoberfläche bietet. Die Handhabung von Disk-Images zusammen mit dem übrigen Speichermanagement in diskutil zu konsolidieren, ist eine schlüssige Richtung. Das ist eine Interpretation der Fakten, keine Aussage von Apple.

Bricht meine App, wenn sie hdiutil aufruft?

In macOS 27 nicht. Planen Sie den Umstieg trotzdem – und nutzen Sie die Fähigkeitsprüfung, damit ein einziger Codepfad beide Fälle abdeckt, was einfacher ist, als es klingt, gerade weil der neue Befehl bereits unter macOS 26 existiert.

Fazit

Die Schlagzeile – ein 25 Jahre alter Terminal-Befehl wird abgeschaltet – stimmt, ist aber in beide Richtungen irreführend. Sie untertreibt die Änderung für alle, deren Build-Skripte verify, compact, makehybrid oder die feingranularen create-Optionen nutzen, weil es dafür heute keinen Weg nach vorn gibt. Und sie übertreibt sie für alle anderen, weil hdiutil in macOS 27 weiterhin funktioniert, Apple kein Entfernungsdatum angekündigt hat und die Veralterung der letzte Schritt einer Beschneidung ist, die bereits seit macOS 10.15 in der eigenen Man-Page des Werkzeugs dokumentiert ist.

Das wirklich Nützliche zu wissen ist, dass der Nachfolger nicht erst noch kommt. diskutil image ist bereits jetzt auf Ihrem Mac, unter macOS 26, mit funktionierendem create, attach, info, resize und chpass. Sie können diese Migration an einem Dienstagnachmittag auf dem OS erledigen, das Sie bereits haben, mit diff -rq verifizieren und dann nicht mehr darüber nachdenken.

Denken Sie nur daran, dass detach nicht dort ist, wo Sie es erwarten.

Weiterführende Lektüre: Terminal-Beherrschung unter macOS, Einrichtung einer Apple-Silicon-Entwicklungsumgebung und verschlüsselte HFS+-Volumes werden in macOS 28 abgeschafft.