hdiutil est déprécié dans macOS 27. Son remplaçant est déjà là.

macOSTahoe ·
hdiutil est déprécié dans macOS 27. Son remplaçant est déjà là.

Apple a déprécié hdiutil dans macOS 27 au profit de diskutil image. Cette commande est déjà présente sur votre Mac aujourd'hui — et il lui manque des choses que vous utilisez probablement.

La page de manuel de macOS 27 Golden Gate comporte une ligne qui n'y a jamais figuré auparavant :

In macOS 27.0, hdiutil is deprecated. Use diskutil image instead for all disk image operations.

hdiutil est le moyen de créer, monter, convertir et inspecter des images disque sur Mac depuis Mac OS X 10.0. Si vous avez déjà distribué un .dmg, scripté un installeur, construit un job CI qui empaquette une app Mac, ou créé un conteneur chiffré pour garder quelque chose de privé, vous l'avez utilisé — directement ou via un outil qui l'appelait pour vous.

Voici ce que la plupart des articles ont manqué : le remplaçant n'arrive pas plus tard. Il est déjà sur votre Mac. Ouvrez Terminal sous macOS 26 Tahoe dès maintenant et exécutez diskutil image. Il répond.

Points clés

  • diskutil image fonctionne déjà sous macOS 26. Vérifié sur macOS 26.5.2 (build 25F84). Vous pouvez migrer et tester vos scripts dès aujourd'hui, avant la sortie de macOS 27.
  • Déprécié ne veut pas dire supprimé. hdiutil fonctionne toujours dans macOS 27. Rien ne casse le premier jour. Mais Apple le réduit progressivement depuis sept ans, et la page de manuel documente chaque étape.
  • La surface de commande est bien plus réduite. hdiutil expose 23 verbes. diskutil image en expose 5.
  • Il n'y a pas de detach. Vous pouvez attacher une image disque avec diskutil image, mais pas la détacher — cela passe désormais par diskutil eject.
  • Certaines fonctions n'ont réellement aucun remplaçant pour l'instant, notamment verify, compact et makehybrid. Si vos scripts de build les utilisent, vous n'avez pas de chemin de migration aujourd'hui.

D'abord : vérifiez-le sur votre propre Mac

Ne me croyez pas sur parole. Une seule commande :

diskutil image

Sous macOS 26.5.2, cela affiche :

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.

Cinq sous-commandes. Comparez maintenant cela avec ce que propose hdiutil, tiré directement de sa propre page de manuel :

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.

Cela fait 23 verbes contre 5 sous-commandes. Ce ratio est alarmant au premier abord, et il est également trompeur, car une comparaison verbe à verbe donne une réponse fausse. Plusieurs verbes de hdiutil sont intégrés dans diskutil image sous des noms différents, plusieurs étaient déjà dépréciés depuis des années, et l'un d'eux, important, est passé sous une commande entièrement différente.

Déterminer qui est qui, c'est ça, la vraie migration. Faisons-le correctement.

Ce n'est pas sorti de nulle part

Avant le tableau de migration, un peu de contexte qui rend la dépréciation moins brutale qu'il n'y paraît. La page de manuel de hdiutil contient une section de compatibilité qui se lit comme sept années d'un rétrécissement progressif de l'outil par Apple. Ceci est sur votre Mac dès maintenant — tapez man hdiutil et cherchez les titres de version :

macOS 10.15

  • Introduction de la compression lzma dans le format ULMO
  • Dépréciation du support des fichiers à double fourche de style OS 9 (hdiutil flatten/unflatten)
  • Suppression de la commande dépréciée hdiutil internet-enable et des flags d'attachement IDME

macOS 11.0

  • Suppression du support des formats DiskCopy42, DART et NDIF
  • Suppression du support des encodages AppleSingle et MacBinary
  • Suppression du support des fichiers à double fourche de style OS 9
  • Changement du système de fichiers par défaut pour les nouvelles images, passé à APFS

macOS 12.0

  • Dépréciation du format UDBZ (compression bzip2)
  • Dépréciation des images UDIF segmentées (hdiutil segment, -segmentSize)
  • Dépréciation de hdiutil udifrez/udifderez (intégration et extraction de ressources)

macOS 13.0

  • Suppression de l'option encrypted-encoding-version ; toutes les nouvelles images chiffrées utilisent désormais la version 2

La page de manuel signale également, en ligne, que -passphrase n'est pas sûr, que les images segmentées sont dépréciées, et que UDBZ est déprécié.

Lue comme un arc continu, la dépréciation de macOS 27 est la dernière étape d'un processus entamé aux alentours de 2019, et non une décision prise cet été. C'est important pour la planification : Apple retire des éléments de cet outil lentement et les annonce d'abord dans la page de manuel. hdiutil dans macOS 27 est déprécié, pas disparu, et aucune date de suppression n'a été annoncée.

Le tableau de migration

Voici la carte. J'ai testé chacun de ces éléments sous macOS 26.5.2.

Ce que vous voulez fairehdiutildiskutil image
Monter une imagehdiutil attach x.dmgdiskutil image attach x.dmg
Démonter une imagehdiutil detach /dev/diskNAbsent de diskutil image — utilisez diskutil eject /dev/diskN
Créer une image viergehdiutil create -size 1g -fs APFS x.dmgdiskutil image create blank --size 1g x.dmg
Créer une image à partir d'un dossierhdiutil create -srcfolder ./dir x.dmgdiskutil image create from ./dir x.dmg
Convertir un formathdiutil convert in.dmg -format UDZO -o out.dmgdiskutil image create from in.dmg out.dmg --format UDZO
Inspecter une imagehdiutil imageinfo x.dmgdiskutil image info x.dmg
Vérifier si elle est chiffréehdiutil isencrypted x.dmgdiskutil image info → Is Encrypted:
Redimensionnerhdiutil resize -size 2g x.dmgdiskutil image resize
Changer le mot de passehdiutil chpass x.dmgdiskutil image chpass x.dmg
Vérifier la somme de contrôlehdiutil verify x.dmgAucun équivalent
Compacter une image sparsehdiutil compact x.sparsebundleAucun équivalent
Créer une image hybride/ISOhdiutil makehybridAucun équivalent
Intégrer un accord de licencehdiutil udifrezAucun équivalent (déprécié depuis macOS 12)
Graver sur un support optiquehdiutil burnAucun équivalent

La surprise du convert

L'erreur la plus fréquente que j'ai vue dans les premiers commentaires est « il n'y a pas de convert ». Si, il y en a un — il ne porte simplement pas ce nom.

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 accepte une image disque comme source ; c'est donc hdiutil convert sous un autre nom, et cela prend en plus en charge la conversion sur place, ce que hdiutil convert n'a jamais su faire. Si vous vous contentez de compter les verbes plutôt que de lire l'aide, vous conclurez qu'une fonctionnalité a été supprimée alors qu'elle a en réalité été étendue.

L'absence de detach est bien réelle

Ce n'est pas un simple renommage. Il n'y a nulle part de detach dans diskutil image :

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

Le remplaçant est la commande diskutil de premier niveau :

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

Ce qui fonctionne parfaitement — mais notez ce que cela fait à un script. La symétrie propre entre hdiutil attach et hdiutil detach devient diskutil image attach / diskutil eject, deux niveaux de sous-commande différents du même binaire. Toute fonction wrapper qui associe attach et detach doit être restructurée, pas simplement retouchée par un rechercher-remplacer.

Migration des scripts d'images disque

Ce que diskutil image fait mieux

Il serait injuste de présenter cela comme une perte pure. Trois points sont réellement améliorés.

ASIF, que hdiutil ne sait pas du tout créer

diskutil image prend en charge l'Apple Sparse Image Format. hdiutil ne le fait pas. Si vous voulez de l'ASIF — et pour les disques de machines virtuelles sur APFS, c'est le format vers lequel Apple oriente les utilisateurs — diskutil image est le seul outil capable de le produire.

Les listes de formats valent la peine d'être connues :

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

Il attache via HTTP et crée des disques RAM directement

Extrait de l'aide d'attach :

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

Créer un disque RAM sous macOS a toujours été une manœuvre en deux temps un peu lourde — hdiutil attach -nomount ram://<sectors> suivi de newfs_hfs ou de diskutil eraseVolume. Ici, c'est un seul argument passé à un flag documenté.

Il est nettement plus rapide

Jeff Johnson, de Lapcat Software, a comparé les deux en enquêtant sur la dépréciation début août 2026, et a mesuré diskutil image réalisant une opération de création en 40 à 45 secondes contre 110 à 115 secondes pour hdiutil, tout en produisant une image plus petite. Ce n'est pas une différence d'arrondi. Pour un job CI qui construit des images disque à chaque commit, c'est significatif.

Ce qui va réellement casser dans vos scripts

Les avertissements de dépréciation ne cassent pas les builds. Ces points-là, si.

1. -puppetstrings n'a pas de remplaçant

Le flag -puppetstrings de hdiutil émet une sortie de progression analysable par une machine, exactement ce qu'un système de build recherche. Johnson signale son absence comme l'un des manques notables. diskutil image propose --plist pour des résultats structurés, et affiche une progression lisible par un humain de ce type :

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

Si votre outillage analyse des lignes PERCENT: provenant de hdiutil, ce parseur n'a plus rien à quoi s'accrocher.

2. Plusieurs options de create ont tout simplement disparu

L'article de Johnson liste -[no]crossdev, -[no]scrub, -[no]anyowners, -skipunreadable, -[no]atomic et -copyuid comme n'ayant aucun équivalent. Si vous construisez des images à partir de dossiers de manière contrôlée — installeurs, captures forensiques, tout cas où la propriété des fichiers ou la sélection exacte des fichiers inclus doit être précise — lisez attentivement cette liste. -skipunreadable et -copyuid en particulier sont critiques pour certains scripts d'empaquetage.

3. Le comportement de nettoyage a changé silencieusement

Johnson rapporte que diskutil image exclut automatiquement les fichiers temporaires tels que les dossiers de corbeille, se comportant comme si -scrub était toujours activé. hdiutil ne nettoyait que sur demande explicite. Si le contenu de votre image est censé être identique octet pour octet à un répertoire source, cela produira une image différente sans vous en avertir.

4. La gestion des permissions échoue silencieusement

C'est celui que je testerais en premier. Johnson a constaté que là où hdiutil déclenche une invite d'authentification en rencontrant des fichiers appartenant à root, diskutil image n'invite pas et échoue simplement. Un script qui marquait autrefois une pause pour demander des identifiants produira désormais une image incomplète et, selon votre gestion des erreurs, pourra signaler un succès.

Si vous construisez des images à partir de répertoires contenant des fichiers dont vous n'êtes pas propriétaire, vérifiez le résultat plutôt que de faire confiance au code de sortie.

5. La journalisation est plus légère

La sortie détaillée de diskutil image est moins fournie que celle de hdiutil. Quand un build échoue à 3 heures du matin, c'est là que vous vous en rendez compte.

Comment migrer sans casser la compatibilité avec macOS 26

La plupart d'entre nous doivent prendre en charge les deux versions pendant un moment. La bonne nouvelle, et le point pratique de tout cet article, c'est que vous n'avez pas besoin de brancher sur la version de l'OS, parce que diskutil image existe déjà sous macOS 26.

Détectez la capacité, pas la 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
}

Vérifiez ensuite le résultat, car c'est là que se nichent les différences silencieuses :

# 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

Ce diff -rq est l'étape que je ne sauterais pas. Entre le nettoyage systématique et les échecs silencieux de permissions, une image qui se construit avec succès n'est pas la même chose qu'une image qui contient réellement ce que vous vouliez.

Si vous mettez en place un environnement de développement Mac depuis zéro, notre guide de configuration d'un environnement de développement Apple silicon couvre l'outillage environnant, et le guide de maîtrise du Terminal couvre les fondamentaux du shell que ces scripts supposent acquis.

Vérification du contenu d'une image disque

Un exemple complet, de bout en bout

Voici un aller-retour complet exécuté sous macOS 26.5.2, pour que vous voyiez la sortie réelle plutôt qu'une reconstitution.

Créer une image à partir d'un dossier :

$ 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

L'inspecter :

$ 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

Notez que info couvre ce que hdiutil imageinfo, isencrypted et une partie de checksum fournissaient auparavant séparément. Elle rapporte la somme de contrôle stockée — elle ne la vérifie pas. C'est là qu'est le manque de hdiutil verify.

L'attacher :

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

La détacher — avec la commande différente :

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

Images chiffrées

Si vous utilisez des images disque comme conteneurs chiffrés, la mécanique est simple mais les options sont plus restreintes.

# 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 est documenté comme utilisant AES-256, et il n'y a pas de choix d'algorithme, ce qui relève d'une simplification plutôt que d'une perte — Apple a retiré l'ancienne version de chiffrement dès macOS 13.

Le flag --stdinpassphrase est celui à utiliser dans tout script. La propre page de manuel de hdiutil avertit que -passphrase n'est pas sûr, pour la raison bien ordinaire qu'un mot de passe passé en ligne de commande est visible dans la table des processus par tout utilisateur de la machine.

Si vous comptez sur les images disque pour la confidentialité plutôt que pour la simple commodité, notre guide de sécurité et confidentialité Mac vaut la lecture pour comprendre où se situe une image chiffrée par rapport à FileVault — ils résolvent des problèmes différents, et un .dmg chiffré ne protège rien tant qu'il est monté.

À quoi servent encore les images disque

Cela vaut la peine de se demander pourquoi tout cela compte, car « image disque » sonne comme une relique alors que l'outillage qui l'entoure reste discrètement essentiel à plusieurs endroits.

Distribution d'applications. Le .dmg reste le moyen standard de distribuer une app Mac en dehors de l'App Store. Une image compressée, en lecture seule, contenant un bundle d'app et un lien symbolique vers /Applications, c'est la convention du glisser-déposer pour installer que connaissent les utilisateurs. Chacune de ces images est construite par un script qui appelle un outil d'image disque.

Conteneurs chiffrés. Un .dmg chiffré est un coffre portable et autonome qui se monte comme un volume et fonctionne sur n'importe quel Mac sans logiciel spécial. Contrairement à FileVault, qui protège un disque entier au repos, une image chiffrée protège un ensemble spécifique de fichiers que vous pouvez déplacer — sur une clé USB, dans un stockage cloud, vers un collègue.

Disques de machines virtuelles. C'est ici qu'ASIF prend tout son sens, et là que la direction prise par Apple devient évidente.

Sparsebundles pour la sauvegarde réseau. Time Machine, quand il sauvegarde vers une destination réseau, stocke la sauvegarde dans un sparsebundle — une image disque découpée en de nombreux petits fichiers de bande, de sorte que seules les bandes modifiées ont besoin d'être synchronisées. Quiconque a entretenu l'un de ces sparsebundles a déjà exécuté hdiutil compact pour récupérer l'espace occupé par des bandes supprimées.

Investigation numérique et archivage. Une image au niveau bloc d'un volume, accompagnée d'une somme de contrôle, est le moyen de préserver l'état exact d'un disque. hdiutil verify est le moyen de le confirmer plus tard.

Mettez cette liste en regard du tableau de migration, et les manques correspondent à des communautés précises plutôt qu'à un hasard. Les développeurs d'applications perdent le mécanisme d'accord de licence et -puppetstrings. Les utilisateurs de sauvegardes et de sparsebundles perdent compact. Les utilisateurs d'archivage et d'investigation numérique perdent verify. Quiconque fait un travail courant de création-conversion-attachement s'en sort bien.

ASIF : le format que seul le nouvel outil sait créer

L'Apple Sparse Image Format est le signal le plus clair de la raison pour laquelle Apple veut éloigner les utilisateurs de hdiutil, car hdiutil ne peut absolument pas le produire.

Une image sparse n'occupe de l'espace disque que pour les blocs qui contiennent réellement des données. Une image sparse de 100 Go contenant 10 Go de fichiers occupe environ 10 Go sur le disque et croît à mesure que vous ajoutez des données. Les anciens formats sparse UDSP et sparsebundle UDSB faisaient déjà cela, avec des problèmes connus : les sparsebundles se fragmentent en milliers de fichiers de bande, et les deux formats récupéraient historiquement mal l'espace, ce qui est précisément la raison d'être de hdiutil compact.

ASIF est conçu directement pour APFS plutôt que greffé par-dessus, ce qui laisse le support natif des fichiers sparse du système de fichiers faire le travail au lieu que le format d'image ne l'émule. En pratique, le gain se manifeste surtout dans la virtualisation, où le disque virtuel d'une VM est un gros fichier essentiellement vide qui change constamment — le cas de figure qui pénalisait le plus durement les anciens formats.

Vous pouvez en créer une dès aujourd'hui :

# 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

Notez que le format est déduit de l'extension — create blank utilise RAW par défaut, « sauf si le chemin de l'image comporte l'extension .asif ou .sparsebundle ». Bien nommer le fichier suffit ; passer également --format relève de la ceinture et des bretelles.

Le compromis, c'est la portabilité. ASIF est récent, et une image ASIF ne s'ouvrira ni sur une version plus ancienne de macOS ni sur quoi que ce soit qui ne soit pas un Mac. Pour un disque de VM ou un volume de travail local, cela n'a aucune importance. Pour tout ce que vous remettez à une autre personne, utilisez UDZO et conservez la compatibilité.

Où cela s'inscrit dans un pipeline de distribution

Si vous distribuez une app Mac en dehors de l'App Store, l'étape d'image disque s'insère au milieu d'une chaîne, et il vaut la peine de voir où atterrit le changement.

#!/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"

Seule l'étape 3 change. La signature, la notarisation et l'agrafage ne sont pas affectés — ils opèrent sur l'image finie et ne se soucient pas de l'outil qui l'a produite.

Deux points à surveiller dans un pipeline réel. D'abord, vérifiez que le contenu mis en scène a bien été inséré correctement, à cause du nettoyage silencieux et du comportement de permissions décrits plus haut — un diff -rq entre $STAGE et le résultat monté est une assurance à faible coût. Ensuite, si votre script actuel intègre un accord de licence avec hdiutil udifrez, cette étape n'a aucun remplaçant et est dépréciée depuis macOS 12. Conservez hdiutil pour cette étape tant qu'il existe, et prévoyez une alternative.

Résolution des problèmes courants

« diskutil image : commande introuvable » ou la sous-commande n'est pas reconnue

Problème : Vous êtes sur une version de macOS antérieure à 26, où le verbe image n'existe pas.

Solution : Utilisez la vérification de capacité présentée plus haut plutôt que de faire une supposition. diskutil image --help >/dev/null 2>&1 renvoie un code non nul sur les systèmes qui en sont dépourvus, ce qui constitue un branchement fiable. Ne testez pas sw_vers — c'est la présence de la sous-commande qui compte réellement.

L'image se construit mais il manque des fichiers

Problème : Deux causes probables. Soit diskutil image a ignoré des fichiers qu'il ne pouvait pas lire avec votre utilisateur sans demander d'authentification, soit son nettoyage systématique a retiré des éléments que hdiutil aurait inclus.

Solution : Montez le résultat et faites un diff -rq avec le répertoire source. Si des fichiers manquent à cause de la propriété, relancez la construction avec les privilèges nécessaires plutôt que d'attendre une invite. Ne vous fiez pas au seul code de sortie.

L'analyse de la progression a cassé en CI

Problème : -puppetstrings n'a pas d'équivalent sous diskutil image, donc les scripts qui analysaient la progression lisible par machine de hdiutil n'ont plus rien à lire.

Solution : Utilisez --plist pour le résultat structuré et considérez que la progression n'est pas disponible. Si votre CI a spécifiquement besoin de la progression, conserver hdiutil pour cette étape est légitime — il est déprécié, pas supprimé, et aucune date de suppression n'a été annoncée.

Impossible de détacher — « resource busy »

Problème : Quelque chose a encore le volume ouvert. Cela se comporte exactement comme avant.

Solution : lsof +D /Volumes/VotreVolume pour trouver le responsable, puis diskutil eject. L'indexation Spotlight et les antivirus sont des coupables fréquents ; monter avec --nobrowse évite une partie du problème en gardant le volume hors du Finder.

Un .dmg avec un accord de licence ne se construit plus

Problème : Le mécanisme d'accord de licence repose sur hdiutil udifrez, qu'Apple a déprécié dès macOS 12 et qui n'a aucun équivalent sous diskutil image.

Solution : Il n'existe aucun chemin de remplacement. Continuez à utiliser hdiutil pour cette étape tant qu'il existe, et prévoyez une méthode de distribution qui ne dépende pas d'un accord intégré. C'est un fait connu depuis quatre ans, ce qui vaut la peine d'être su si vous ne le découvrez que maintenant.

FAQ

hdiutil fonctionne-t-il toujours dans macOS 27 ?

Oui. Il est déprécié, pas supprimé. La dépréciation est un signal d'intention de la part d'Apple qui déclenche un compte à rebours — ce n'est pas un changement fonctionnel. Rien de ce qui fonctionne aujourd'hui ne cesse de fonctionner lorsque vous installez macOS 27.

Quand hdiutil sera-t-il effectivement supprimé ?

Apple ne l'a pas précisé. À en juger par l'historique propre de la page de manuel, le schéma habituel d'Apple avec cet outil a été de déprécier une fonctionnalité dans une version et de la supprimer une ou plusieurs versions majeures plus tard — internet-enable et le support des fichiers à double fourche d'OS 9 ont chacun mis au moins un cycle complet. Quiconque vous donne une version de suppression précise fait une supposition.

Puis-je utiliser diskutil image sous macOS 26 Tahoe ?

Oui, et c'est le fait le plus utile de cet article. Vérifié sur macOS 26.5.2 (build 25F84). Vous pouvez migrer vos scripts et les tester dès maintenant, sur l'OS que vous utilisez déjà, plutôt que d'attendre macOS 27.

diskutil image remplace-t-il intégralement hdiutil ?

Non, pas aujourd'hui. verify, compact, makehybrid et burn n'ont aucun équivalent, et plusieurs options de create permettant de contrôler exactement quels fichiers sont inclus sont absentes. Pour le chemin courant — création, conversion, attachement, inspection, redimensionnement, chiffrement — il est complet.

Pourquoi Apple a-t-il fait cela ?

Apple n'a publié aucune justification. Ce qu'on peut observer, c'est que diskutil image est plus rapide dans les benchmarks, produit des images plus petites, prend en charge le format ASIF plus récent que hdiutil ne peut pas produire, et présente une surface de commande bien plus réduite. Consolider la gestion des images disque au sein de diskutil, aux côtés du reste de la gestion du stockage, est une direction cohérente. C'est une lecture des indices disponibles, pas une déclaration d'Apple.

Mon application va-t-elle casser si elle exécute hdiutil ?

Pas dans macOS 27. Prévoyez tout de même de migrer — et utilisez la vérification de capacité pour qu'un seul chemin de code couvre les deux cas, ce qui est plus simple qu'il n'y paraît, précisément parce que la nouvelle commande existe déjà sous macOS 26.

Conclusion

Le titre accrocheur — une commande Terminal vieille de 25 ans part à la retraite — est vrai mais trompeur dans les deux sens. Il sous-estime le changement pour quiconque a des scripts de build utilisant verify, compact, makehybrid, ou les options fines de create, parce que celles-ci n'ont aucun chemin de remplacement aujourd'hui. Et il le surestime pour tous les autres, parce que hdiutil fonctionne toujours dans macOS 27, qu'Apple n'a annoncé aucune date de suppression, et que la dépréciation est la dernière étape d'un rétrécissement documenté dans la propre page de manuel de l'outil depuis macOS 10.15.

Le fait réellement utile à retenir, c'est que le remplaçant n'appartient pas au futur. diskutil image est sur votre Mac dès maintenant, sous macOS 26, avec create, attach, info, resize et chpass opérationnels. Vous pouvez faire cette migration un mardi après-midi, sur l'OS que vous avez déjà, la vérifier avec diff -rq, et ne plus y penser.

Souvenez-vous simplement que detach ne se trouve pas là où vous l'attendez.

Lecture connexe : maîtriser le Terminal sous macOS, configuration d'un environnement de développement Apple silicon, et les volumes HFS+ chiffrés sont abandonnés dans macOS 28.