O hdiutil Foi Descontinuado no macOS 27. O Substituto Já Chegou.
A Apple descontinuou o hdiutil no macOS 27 em favor do diskutil image. Esse comando já está no seu Mac hoje — e está sem coisas que você provavelmente usa.
A man page do macOS 27 Golden Gate traz uma linha que nunca esteve lá antes:
No macOS 27.0, o hdiutil está descontinuado. Use o diskutil image em vez dele para todas as operações com imagens de disco.
O hdiutil é a forma de criar, montar, converter e inspecionar imagens de disco no Mac desde o Mac OS X 10.0. Se você já lançou um .dmg, escreveu um script de instalador, construiu um job de CI que empacota um app para Mac, ou criou um contêiner criptografado para manter algo privado, você já o usou — diretamente ou através de algo que o chamou por você.
Aqui está a parte que a maioria das coberturas deixou passar: o substituto não está a caminho. Ele já está no seu Mac. Abra o Terminal no macOS 26 Tahoe agora mesmo e execute diskutil image. Ele responde.
Principais Conclusões
- O
diskutil imagejá funciona no macOS 26. Verificado no macOS 26.5.2 (build 25F84). Você pode migrar e testar scripts hoje, antes do lançamento do macOS 27. - Descontinuado não é removido. O
hdiutilcontinua funcionando no macOS 27. Nada quebra no primeiro dia. Mas a Apple vem reduzindo o comando há sete anos, e a man page documenta cada etapa. - A superfície de comandos é muito menor. O
hdiutilexpõe 23 verbos. Odiskutil imageexpõe 5 subcomandos. - Não existe
detach. Você pode anexar (attach) uma imagem de disco comdiskutil image, mas não desanexá-la (detach) — isso passa para odiskutil eject. - Algumas coisas realmente ainda não têm substituto, incluindo
verify,compactemakehybrid. Se seus scripts de build usam esses comandos, você não tem um caminho de migração hoje.
Primeiro: Confirme No Seu Próprio Mac
Não confie apenas na minha palavra para nada disso. Um comando:
diskutil image
No macOS 26.5.2, isso imprime:
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.
Cinco subcomandos. Agora compare isso com o que o hdiutil oferece, direto da própria 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.
São 23 verbos contra 5 subcomandos. Essa proporção é alarmante à primeira vista e também é enganosa, porque uma comparação direta verbo a verbo chega à resposta errada. Vários verbos do hdiutil foram incorporados ao diskutil image sob outros nomes, vários já estavam descontinuados havia anos, e um importante migrou por completo para um comando diferente.
Descobrir o que é o quê é a verdadeira migração, então vamos fazer isso direito.
Isso Não Surgiu do Nada
Antes da tabela de migração, um pouco de contexto que torna a descontinuação menos abrupta. A man page do hdiutil contém uma seção de compatibilidade que funciona como um registro de sete anos da Apple restringindo a ferramenta. Isso está no seu Mac agora mesmo — rode man hdiutil e procure pelos títulos de versão:
macOS 10.15
- Introduziu a compressão lzma no formato ULMO
- Descontinuou o suporte a arquivos de fork duplo no estilo OS 9 (
hdiutil flatten/unflatten) - Removeu o comando descontinuado
hdiutil internet-enablee as flags de attach do IDME
macOS 11.0
- Removeu o suporte aos formatos DiskCopy42, DART e NDIF
- Removeu o suporte às codificações AppleSingle e MacBinary
- Removeu o suporte a arquivos de fork duplo no estilo OS 9
- Mudou o sistema de arquivos padrão para novas imagens para APFS
macOS 12.0
- Descontinuou o formato UDBZ (compressão bzip2)
- Descontinuou imagens UDIF segmentadas (
hdiutil segment,-segmentSize) - Descontinuou
hdiutil udifrez/udifderez(incorporar e extrair recursos)
macOS 13.0
- Removeu a opção
encrypted-encoding-version; todas as novas imagens criptografadas usam a versão 2
A man page também sinaliza, no próprio texto, que -passphrase é inseguro, que imagens segmentadas estão descontinuadas e que o UDBZ está descontinuado.
Lida como um arco contínuo, a descontinuação no macOS 27 é a última etapa de um processo que começou por volta de 2019, não uma decisão tomada neste verão. Isso importa para o planejamento: a Apple remove coisas dessa ferramenta lentamente e as anuncia primeiro na man page. O hdiutil no macOS 27 está descontinuado, não desapareceu, e não há data de remoção anunciada.
A Tabela de Migração
Este é o mapa. Testei cada um destes itens no macOS 26.5.2.
| O que você quer | hdiutil | diskutil image |
|---|---|---|
| Montar uma imagem | hdiutil attach x.dmg | diskutil image attach x.dmg |
| Desmontar uma imagem | hdiutil detach /dev/diskN | Não existe em diskutil image — use diskutil eject /dev/diskN |
| Criar uma imagem em branco | hdiutil create -size 1g -fs APFS x.dmg | diskutil image create blank --size 1g x.dmg |
| Criar uma imagem a partir de uma pasta | hdiutil create -srcfolder ./dir x.dmg | diskutil image create from ./dir x.dmg |
| Converter formato | hdiutil convert in.dmg -format UDZO -o out.dmg | diskutil image create from in.dmg out.dmg --format UDZO |
| Inspecionar uma imagem | hdiutil imageinfo x.dmg | diskutil image info x.dmg |
| Verificar se está criptografada | hdiutil isencrypted x.dmg | diskutil image info → Is Encrypted: |
| Redimensionar | hdiutil resize -size 2g x.dmg | diskutil image resize |
| Alterar a senha (passphrase) | hdiutil chpass x.dmg | diskutil image chpass x.dmg |
| Verificar checksum | hdiutil verify x.dmg | Sem equivalente |
| Compactar uma imagem esparsa | hdiutil compact x.sparsebundle | Sem equivalente |
| Criar uma imagem híbrida/ISO | hdiutil makehybrid | Sem equivalente |
| Incorporar um contrato de licença | hdiutil udifrez | Sem equivalente (descontinuado no macOS 12) |
| Gravar em mídia óptica | hdiutil burn | Sem equivalente |
A surpresa do convert
O erro mais comum que vi nos primeiros comentários é dizer que "não existe convert". Existe sim — só não se chama assim.
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.
O diskutil image create from aceita uma imagem de disco como origem, então ele é o hdiutil convert com outro nome, e além disso suporta conversão no local (in-place), algo que o hdiutil convert nunca fez. Se você contar verbos em vez de ler o texto de ajuda, vai concluir que um recurso foi removido quando na verdade ele foi ampliado.
A lacuna do detach é real
Este caso não é uma simples renomeação. Não existe detach em lugar nenhum do diskutil image:
$ diskutil image detach /dev/disk12
Error: 2 unexpected arguments: 'detach', '/dev/disk12'
Usage: diskutil image [--verbose] [--stdinpassphrase] [--plist] <subcommand>
O substituto é o comando diskutil de nível superior:
$ diskutil eject /dev/disk12
Disk /dev/disk12 ejected
O que funciona bem — mas note o que isso faz com um script. A simetria limpa de hdiutil attach / hdiutil detach vira diskutil image attach / diskutil eject, dois níveis diferentes de subcomando do mesmo binário. Qualquer função wrapper que você tenha que combine attach e detach precisa ser reestruturada, não apenas passar por um find-and-replace.

O Que o diskutil image Faz Melhor
Seria injusto apresentar isso como pura perda. Três coisas foram genuinamente melhoradas.
ASIF, que o hdiutil simplesmente não consegue criar
O diskutil image suporta o Apple Sparse Image Format (ASIF). O hdiutil não. Se você quer ASIF — e, para discos de máquina virtual em APFS, é o formato para o qual a Apple vem direcionando — o diskutil image é a única ferramenta que o produz.
Vale a pena conhecer as listas de formatos:
create blank --format : RAW, ASIF, UDSB (default RAW)
create from --format : ASIF, RAW, UDRO, UDSB,
UDZO, ULFO, ULMO (default ULFO)
Ele anexa via HTTP e cria discos RAM diretamente
Do texto de ajuda do attach:
Supports 'ram://<size>', file paths, http[s].
Criar um disco RAM no macOS tradicionalmente era o incômodo processo em duas etapas: hdiutil attach -nomount ram://<sectors> seguido de newfs_hfs ou diskutil eraseVolume. Aqui é um único argumento em uma flag documentada.
É substancialmente mais rápido
Jeff Johnson, da Lapcat Software, comparou os dois enquanto investigava a descontinuação no início de agosto de 2026, e mediu o diskutil image completando uma operação de criação em 40–45 segundos contra 110–115 segundos do hdiutil, produzindo uma imagem menor no processo. Isso não é uma diferença de arredondamento. Para um job de CI que constrói imagens de disco a cada commit, isso é significativo.
O Que Realmente Vai Quebrar Nos Seus Scripts
Avisos de descontinuação não quebram builds. Estas coisas vão quebrar.
1. O -puppetstrings não tem substituto
A flag -puppetstrings do hdiutil emite uma saída de progresso legível por máquina, que é exatamente o que um sistema de build quer. Johnson aponta essa ausência como uma das lacunas notáveis. O diskutil image tem --plist para resultados estruturados, e imprime progresso legível para humanos assim:
[5% completed] [79% completed] [98% completed] [100% completed]
test.dmg created
Se você tem ferramentas que fazem parsing de linhas PERCENT: do hdiutil, esse parser não vai ter a que se conectar.
2. Várias opções do create simplesmente desapareceram
O texto de Johnson lista -[no]crossdev, -[no]scrub, -[no]anyowners, -skipunreadable, -[no]atomic e -copyuid como sem correspondente. Se você constrói imagens a partir de pastas de forma controlada — instaladores, capturas forenses, qualquer coisa em que a propriedade dos arquivos ou quais arquivos são incluídos precisam ser exatos — leia essa lista com atenção. -skipunreadable e -copyuid, em particular, são estruturais para alguns scripts de empacotamento.
3. O comportamento de scrubbing mudou silenciosamente
Johnson relata que o diskutil image exclui automaticamente arquivos temporários, como pastas de lixeira, comportando-se como se -scrub estivesse sempre ativado. O hdiutil só fazia o scrub quando solicitado. Se você espera que o conteúdo da sua imagem seja byte a byte idêntico a um diretório de origem, isso vai produzir uma imagem diferente sem avisar.
4. O tratamento de permissões falha silenciosamente
Este é o que eu testaria primeiro. Johnson descobriu que, onde o hdiutil dispara um prompt de autenticação ao encontrar arquivos de propriedade do root, o diskutil image não pede nada e simplesmente falha. Um script que costumava pausar para pedir credenciais agora vai produzir uma imagem incompleta e, dependendo do seu tratamento de erros, pode reportar sucesso.
Se você constrói imagens a partir de diretórios que contêm arquivos que não são seus, verifique a saída em vez de confiar no código de saída (exit code).
5. O log é mais enxuto
A saída detalhada (verbose) do diskutil image é menos completa do que a do hdiutil. Quando um build falha às 3 da manhã, é aí que você descobre isso.
Como Migrar Sem Quebrar o Suporte ao macOS 26
A maioria de nós precisa dar suporte aos dois por um tempo. A boa notícia, e o ponto prático deste artigo inteiro, é que você não precisa ramificar (branch) por versão do sistema, porque o diskutil image também existe no macOS 26.
Detecte a capacidade, não a versão:
#!/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
}
Depois verifique a saída, porque é aí que vivem as diferenças silenciosas:
# 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
Esse diff -rq é a etapa que eu não pularia. Entre o scrubbing sempre ativo e as falhas silenciosas de permissão, uma imagem que constrói com sucesso não é a mesma coisa que uma imagem que contém o que você pretendia.
Se você está montando um ambiente de desenvolvimento Mac do zero, nosso guia de configuração de ambiente de desenvolvimento para Apple silicon cobre as ferramentas ao redor, e o guia de domínio do Terminal cobre os fundamentos de shell que esses scripts pressupõem.

Um Exemplo Prático, do Início ao Fim
Aqui está um ciclo completo executado no macOS 26.5.2, para que você veja a saída real em vez de uma reconstrução.
Criar uma imagem a partir de uma pasta:
$ 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
Inspecionar:
$ 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
Note que o info cobre o que hdiutil imageinfo, isencrypted e parte do checksum costumavam entregar separadamente. Ele reporta o checksum armazenado — não o verifica. Essa é a lacuna do hdiutil verify.
Anexar (attach):
$ diskutil image attach test.dmg
/dev/disk12 GUID_partition_scheme
/dev/disk13s1 Apple_APFS_Volume /Volumes/src
Desanexar (detach) — com o comando diferente:
$ diskutil eject /dev/disk12
Disk /dev/disk12 ejected
Imagens Criptografadas
Se você usa imagens de disco como contêineres criptografados, a mecânica é direta, mas as opções são mais restritas.
# 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
O --encrypt é documentado como AES-256 e não há escolha de algoritmo, o que é uma simplificação, não uma perda — a Apple removeu a versão de codificação criptografada mais antiga lá no macOS 13.
A flag --stdinpassphrase é a que você deve usar em qualquer script. A própria man page do hdiutil avisa que -passphrase é inseguro, pelo motivo simples de que uma senha na linha de comando fica visível na tabela de processos para todos os usuários da máquina.
Se você depende de imagens de disco para privacidade, e não apenas por conveniência, vale a pena ler nosso guia de segurança e privacidade no Mac para entender onde uma imagem criptografada se encaixa em relação ao FileVault — eles resolvem problemas diferentes, e um .dmg criptografado não protege nada enquanto está montado.
Para Que Servem as Imagens de Disco Hoje
Vale a pena perguntar por que qualquer coisa disso importa, porque "imagem de disco" soa como uma relíquia, mas o ferramental ao redor dela é discretamente estrutural em vários lugares.
Distribuição de aplicativos. O .dmg continua sendo a forma padrão de lançar um app para Mac fora da App Store. Uma imagem compactada, somente leitura, contendo um app bundle e um symlink para /Applications, é a convenção de arrastar-para-instalar que os usuários conhecem. Cada uma dessas imagens é construída por um script que chama uma ferramenta de imagem de disco.
Contêineres criptografados. Um .dmg criptografado é um cofre portátil e autocontido que monta como um volume e funciona em qualquer Mac sem software especial. Diferente do FileVault, que protege um disco inteiro em repouso, uma imagem criptografada protege um conjunto específico de arquivos que você pode mover — para um pendrive, para armazenamento em nuvem, para um colega.
Discos de máquina virtual. É aqui que o ASIF importa e onde a direção da Apple fica óbvia.
Sparsebundles para backup em rede. Quando o Time Machine faz backup para um destino de rede, ele armazena o backup dentro de um sparsebundle — uma imagem de disco dividida em muitos arquivos de banda pequenos, de modo que só as bandas alteradas precisam ser sincronizadas. Quem já manteve um desses já rodou hdiutil compact para recuperar espaço de bandas excluídas.
Forense e arquivamento. Uma imagem em nível de bloco de um volume, com um checksum, é como você preserva o estado exato de um disco. O hdiutil verify é como você confirma isso depois.
Compare essa lista com a tabela de migração e as lacunas se alinham com comunidades específicas, em vez de serem aleatórias. Desenvolvedores de apps perdem o mecanismo de contrato de licença e o -puppetstrings. Usuários de backup e sparsebundle perdem o compact. Usuários de arquivamento e forense perdem o verify. Todo mundo que faz o trabalho rotineiro de criar-converter-anexar fica bem.
ASIF: O Formato Que Só a Nova Ferramenta Cria
O Apple Sparse Image Format é o sinal mais claro de por que a Apple quer que as pessoas deixem de usar o hdiutil, porque o hdiutil simplesmente não consegue produzi-lo.
Uma imagem esparsa só ocupa espaço em disco para blocos que realmente contêm dados. Uma imagem esparsa de 100 GB guardando 10 GB de arquivos ocupa cerca de 10 GB no disco e cresce conforme você adiciona dados. Os antigos formatos de imagem esparsa UDSP e de sparsebundle UDSB também faziam isso, com problemas conhecidos: sparsebundles se fragmentam em milhares de arquivos de banda, e ambos os formatos historicamente recuperavam espaço mal, motivo exato pelo qual o hdiutil compact precisava existir.
O ASIF é projetado em conjunto com o APFS, e não simplesmente encaixado por cima dele, o que permite que o próprio suporte a arquivos esparsos do sistema de arquivos faça o trabalho, em vez do formato de imagem ter que emulá-lo. Na prática, o ganho aparece mais na virtualização, onde o disco virtual de uma VM é um arquivo grande, majoritariamente vazio, que muda constantemente — o caso que mais penalizava os formatos antigos.
Você pode criar um hoje mesmo:
# 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
Note que o formato é inferido pela extensão — por padrão, create blank usa RAW, "a menos que o caminho da imagem tenha extensão .asif ou .sparsebundle". Nomear o arquivo corretamente já é suficiente; passar --format também é apenas uma garantia extra.
O trade-off é a portabilidade. O ASIF é novo, e uma imagem ASIF não vai abrir em um macOS mais antigo ou em qualquer coisa que não seja um Mac. Para um disco de VM ou um volume de trabalho local, isso é irrelevante. Para qualquer coisa que você vá entregar a outra pessoa, use UDZO e mantenha a compatibilidade.
Onde Isso Se Encaixa em um Pipeline de Distribuição
Se você lança um app para Mac fora da App Store, a etapa de imagem de disco fica no meio de uma cadeia, e vale a pena ver onde a mudança se encaixa.
#!/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"
Só a etapa 3 muda. Assinatura (signing), notarização (notarization) e stapling não são afetados — eles operam sobre a imagem finalizada e não se importam com qual ferramenta a produziu.
Duas coisas para observar em um pipeline real. Primeiro, verifique se o conteúdo preparado (staged) chegou corretamente, por causa do scrubbing silencioso e do comportamento de permissões descritos acima — um diff -rq entre $STAGE e o resultado montado é um seguro barato. Segundo, se o seu script atual incorpora um contrato de licença com hdiutil udifrez, essa etapa não tem substituto e está descontinuada desde o macOS 12. Continue usando o hdiutil para isso enquanto ele existir e planeje uma alternativa.
Solucionando Problemas Comuns
"diskutil image: command not found" ou o subcomando não é reconhecido
Problema: Você está em uma versão do macOS anterior à 26, onde o verbo image não existe.
Solução: Use a verificação de capacidade mostrada acima, em vez de presumir. diskutil image --help >/dev/null 2>&1 retorna um valor diferente de zero em sistemas que não têm o subcomando, o que é um branch confiável. Não teste sw_vers — o que realmente importa é a presença do subcomando.
A imagem é construída, mas faltam arquivos
Problema: Duas causas prováveis. Ou o diskutil image pulou arquivos que não conseguiu ler como seu usuário e não pediu autenticação, ou o scrubbing sempre ativo removeu itens que o hdiutil teria incluído.
Solução: Monte o resultado e rode diff -rq contra o diretório de origem. Se faltam arquivos por causa de propriedade, execute o build com os privilégios necessários em vez de esperar um prompt. Não confie apenas no código de saída.
O parsing de progresso quebrou no CI
Problema: O -puppetstrings não tem equivalente no diskutil image, então scripts que faziam parsing do progresso legível por máquina do hdiutil não têm mais nada para ler.
Solução: Use --plist para o resultado estruturado e trate o progresso como indisponível. Se o seu CI precisa especificamente de progresso, manter o hdiutil para essa etapa é legítimo — ele está descontinuado, não removido, e não há data de remoção anunciada.
Não consigo dar detach — "resource busy"
Problema: Algo ainda está com o volume aberto. Isso se comporta como sempre se comportou.
Solução: lsof +D /Volumes/YourVolume para encontrar quem está segurando o volume, depois diskutil eject. A indexação do Spotlight e scanners de antivírus são culpados frequentes; montar com --nobrowse evita parte disso mantendo o volume fora do Finder.
Um .dmg com contrato de licença não é mais construído
Problema: O mecanismo de contrato de licença depende do hdiutil udifrez, que a Apple descontinuou lá no macOS 12 e que não tem correspondente no diskutil image.
Solução: Não há caminho de substituição. Continue usando o hdiutil para essa etapa enquanto ele existir, e planeje um método de distribuição que não dependa de um contrato incorporado. Isso está avisado há quatro anos, o que vale a pena saber se você só está descobrindo isso agora.
Perguntas Frequentes
O hdiutil ainda funciona no macOS 27?
Sim. Ele está descontinuado, não removido. Descontinuação é a Apple sinalizando intenção e iniciando uma contagem regressiva — não é uma mudança funcional. Nada que funciona hoje para de funcionar quando você instala o macOS 27.
Quando o hdiutil será de fato removido?
A Apple não disse. Olhando para o próprio histórico da man page, o padrão da Apple com essa ferramenta tem sido descontinuar um recurso em uma versão e removê-lo uma ou mais versões principais depois — o internet-enable e o suporte a fork duplo do OS 9 levaram, cada um, pelo menos um ciclo completo. Qualquer pessoa que te dê uma versão específica de remoção está chutando.
Posso usar o diskutil image no macOS 26 Tahoe?
Sim, e esse é o fato mais útil deste artigo. Verificado no macOS 26.5.2 (build 25F84). Você pode migrar scripts e testá-los agora, no sistema que já está rodando, em vez de esperar pelo macOS 27.
O diskutil image é um substituto completo do hdiutil?
Não, ainda não hoje. verify, compact, makehybrid e burn não têm correspondente, e várias opções do create para controlar exatamente quais arquivos são incluídos estão ausentes. Para o caminho comum — criar, converter, anexar, inspecionar, redimensionar, criptografar — ele é completo.
Por que a Apple fez isso?
A Apple não publicou uma justificativa. O que se observa é que o diskutil image é mais rápido em benchmarks, produz imagens menores, suporta o formato ASIF, mais novo, que o hdiutil não consegue produzir, e apresenta uma superfície de comandos muito menor. Consolidar o tratamento de imagens de disco no diskutil, junto com o resto do gerenciamento de armazenamento, é uma direção coerente. Essa é uma leitura das evidências, não uma declaração da Apple.
Meu app vai quebrar se ele chamar o hdiutil via shell?
Não no macOS 27. Planeje migrar de qualquer forma — e use a verificação de capacidade para que um único caminho de código cubra os dois casos, o que é mais fácil do que parece, precisamente porque o novo comando já existe no macOS 26.
Conclusão
A manchete — um comando do Terminal de 25 anos está sendo aposentado — é verdadeira, mas enganosa nas duas direções. Ela subestima a mudança para quem tem scripts de build que usam verify, compact, makehybrid ou as opções refinadas do create, porque esses recursos não têm caminho à frente hoje. E ela superestima a mudança para todo o resto, porque o hdiutil continua funcionando no macOS 27, a Apple não anunciou nenhuma data de remoção, e a descontinuação é a última etapa de uma redução documentada na própria man page da ferramenta desde o macOS 10.15.
A coisa genuinamente útil de saber é que o substituto não está no futuro. O diskutil image está no seu Mac agora mesmo, no macOS 26, com create, attach, info, resize e chpass funcionando. Você pode fazer essa migração em uma tarde de terça-feira, no sistema que já tem, verificar com diff -rq e parar de pensar nisso.
Só lembre que o detach não está onde você espera.
Leitura relacionada: domínio do Terminal no macOS, configuração de ambiente de desenvolvimento para Apple silicon, e volumes HFS+ criptografados estão sendo descontinuados no macOS 28.
