Have you ever wondered whether someone else has changed your Mac’s storage? Or which version of macOS formatted each of its volumes? As all good forensic investigators know, APFS keeps detailed records of the formatting and modification of each volume. This article explains how you can read and interpret them. As in the tale of Goldilocks and the Three Bears, you may be able to tell who has been eating your APFS porridge.

Information available

Each APFS volume stores details of its history in the volume superblock apfs_superblock_t. Those include information on how that volume was created in apfs_formatted_by, and up to the last 8 times the volume has been modified, in apfs_modified_by.

Although you’ll need a forensic disk analysis tool to get full details, some of that data is easy to access. Select a volume in the Finder, and Get Info will give a time and date that volume was last formatted.

Run First Aid in Disk Utility on that volume’s container, and there’s even more information given about each volume within the container, including those you can’t see. If you’d rather not run a full check and repair, then you should see the same information in Terminal by using
diskutil verifyVolume disk10
where disk10 is the device name for the container. If you prefer you can use fsck_apfs directly, but verifyVolume should use that command’s options most efficiently.

One lingering problem you may encounter in Disk Utility is that it still fails frequently because it can’t unmount volumes for checking. If you encounter that error when trying to run First Aid on a container, try manually unmounting each volume within that container. If all else fails, diskutil verifyVolume appears to be better at handling the problem.

Workthrough

As shown above, when run on one of my external SSDs, information about two APFS volumes was returned, itself something of a surprise. The volume I expected gave
The volume ThunderBay3 was formatted by diskmanagementd (1412.81.1) and last modified by apfs_kext (2313.1.2).
and the surprise, which isn’t mounted, thus effectively hidden, gave
The volume Update was formatted by com.apple.Mobile (1677.50.1) and last modified by apfs_kext (1677.141.2).
The Finder’s Get Info dialog for ThunderBay3 gave a volume creation date of 11 February 2020, and last modification of 20 December 2020.

Taking the visible volume ThunderBay3 first, APFS says that it was formatted by its own formatting tool, diskmanagementd, in APFS version 1412.81.1, which came in macOS 10.15 Catalina (see the Appendix below). A look through details of versions released pins that down to 10.15.3, released on 28 January 2020, which tallies with the creation date from the Finder. Its last modification was performed by a general APFS function, in APFS version 2313.1.2, which is that current for macOS 15.0 and 15.0.1.

The hidden Update volume has had quite a different history, as it was created in APFS version 1677.50.1 in Big Sur, to be more precise in macOS 11.0.1 released on 12 November 2021. That wasn’t a conventional volume creation either, and was performed by com.apple.Mobile, part of the Big Sur installer. It was last modified using APFS version 1677.141.2, which came in macOS 11.6 on 13 September 2021. Since then it appears to have been left unmounted and unused.

The history of that container therefore reads:

• ThunderBay3 created by the user on 11 February 2020 in macOS 10.15.3
• Update created by a macOS installer after 12 November 2021 in macOS 11.0.1
• Update last mounted after 13 September 2021 in macOS 11.6
• ThunderBay3 currently in use.

Conclusions

The hidden Update volume contains a restore log apparently left behind after the 11.5.2 update, together with some empty folders. These demonstrate that it was a temporary volume created by Big Sur’s new macOS installer, but never cleaned up afterwards, and left abandoned for the last three years. As Big Sur was the first version of macOS to use Apple’s new installer that created a Signed System Volume, this is likely to be present on other external disks that were mounted when any version of Big Sur was installed. Although it takes little space, it’s a surprising omission that no subsequent installer has seen fit to clean this up by deleting the volume.

Otherwise, information about the visible and mounted volume appears consistent, and confirms what I recall of its history. No one has been eating this bear’s APFS porridge.

Appendix: APFS and macOS version details

APFS major version numbers change with major version of macOS:

• APFS version 0.3 or 249.x.x in macOS 10.12
• 748.x.x in 10.13
• 945.x.x in 10.14
• 1412.x.x in 10.15
• 1677.x.x in macOS 11
• 1933.x.x in 12.0-12.2.1
• 1934.x.x 12.3 and later
• 2142.x.x in 13
• 2235.x.x in 14.0-14.3.1
• 2236.x.x in 14.4 and later
• 2313.x.x in 15.

Minor version numbers increment according to the minor version of macOS, and patch numbers wander without pattern. Those can be checked by looking at the changes given for each macOS update listed on this page.

If you’re going to use disk images of any type, then getting the right tool for the job is essential. This article considers the leading candidates:

• Disk Utility, bundled with macOS
• DropDMG, $24.99 from C-Command, or from the App Store
• Spundle, free from its Product Page here
• hdiutil, the command tool bundled with macOS.

Although I’m sure there are a great many others, IMHO those should be at the top of your list.

Disk Utility

Create a new disk image using the New Image command in its File menu and there’s a basic range of choices on offer.

This dialog has a longstanding bug, where it can reset the size you’ve entered if you change another setting, which can help you make mistakes. Otherwise, it gives limited access to some of the many options available, sufficient for the occasional and not too demanding user. Further options are available in its Images menu, including verification, adding checksums, conversions between types, and resizing. Notable by its absence is the ability to change the password of an encrypted disk image, which is unhelpfully deferred to the command line.

Documentation in Disk Utility’s Help book is also scant, and insufficient to serve as a reference. As Apple doesn’t provide any further technical information, apart from that in man hdiutil, you may find yourself searching websites such as this.

DropDMG

Since its release over 22 years ago, this has been the first choice for many who need to work with disk images, and is without doubt the best for those who distribute software in disk images. It has grown into the most comprehensive and capable utility for working with any type of disk image, and is backed up by a superb 123-page manual that goes a long way to filling the gap left by Apple. That manual is well-maintained, and contains links to recent technical articles and further information.

DropDMG’s options for creating a new disk image far exceed those in Disk Utility. Particularly helpful are the compatible version hints shown on various options, to remind you of which file systems are available in different macOS versions, and which types of disk image container are supported. DropDMG will even convert old NDIF disk images last used in Mac OS 9 to more modern formats. It will also change the password of an encrypted disk image from a menu command.

For those who need to work with standard configurations, perhaps for software distribution, it lets you save and reuse them with ease. Those can include signing with developer certificates, product licences, background images, custom volume icons, and more. Whichever type of disk image you want to create or maintain, DropDMG should be your first choice.

Spundle

There are a few options for sparse bundles that even DropDMG doesn’t expose, such as control over band size, the ability to resize a sparse bundle, and to change its band size. If you want access to those, Spundle is a useful adjunct.

Note that, unlike DropDMG, Spundle only works with sparse bundles.

hdiutil

Although this remains the definitive command tool that offers types of disk image and features you didn’t even know existed, it’s fiendishly complex to use, with a sprawling and overloaded grammar. Its man page runs to more than 11,000 words, but appears never to have been rewritten into any cohesive account of disk images, or command options. For example, change information is given in two sections, Compatibility and What’s New. Changes made in Catalina and later appear at the end of the Compatibility section, then the final What’s New section reverses time order and goes back from Catalina to Mac OS X 10.5.

I only recommend hdiutil for those who need to work with disk images in shell scripts, or for those few features that aren’t available in DropDMG or, for sparse bundles, in Spundle. It’s a command tool of last resort.

Previous article

Introduction

A disk image is a file or a bundle containing what could otherwise be the contents of a disk. It’s a common way to store and move complete file systems in a neat package, for items that need to be separated from the physical storage provided by a drive. macOS uses disk images for some tasks of great importance, including:

• Recovery and Hardware Diagnostics systems,
• additions to macOS such as Safari, its supporting frameworks, and dyld caches, in cryptexes,
• networked storage for Time Machine backups, in sparse bundles,
• lightweight virtual machines on Apple silicon Macs.

You could use them to store encrypted data on unencrypted volumes, and they’re often used for delivering Apple and third-party software.

Disk images are poorly documented for both users and developers, and have changed significantly over the last few years. Articles in this series explain how to choose between different types of disk image, how to create and use them, and what to do when they go wrong.

Containers and file systems

Disk images consist of two distinct components: the file or bundle itself functioning as a container, and the file system contained inside it. When referred to in this context, disk image containers are completely unrelated to the sandbox containers found in ~/Library/Containers.

This distinction is important in several respects, although it isn’t apparent when you use disk images in the Finder. Preparing a disk image for access involves two separate functions: attaching its container, and mounting any file systems found inside it. When that’s performed by the Finder, perhaps by double-clicking the disk image, those two actions appear fused into one. Similarly, removing the disk image requires all its mounted file systems to be unmounted first, then the container is detached.

One feature that’s widely confused is the encrypted disk image. This involves encryption of the whole container, rather than using an encrypted file system within it. Now that Disk Utility no longer supports the creation of encrypted HFS+ volumes, one remaining alternative is to use an encrypted disk image containing an HFS+ volume.

If you want an analogy for disk images, attaching the container is like connecting an external disk, and once that has been performed, the file systems contained by that disk have to be mounted before you can access their contents.

Types

There are many different types of disk image in use, of which the two this series is most concerned with are plain UDIF read-write disk images (UDRW), and sparse bundles (UDSB). Others you may encounter include:

• plain UDIF read-only (UDRO),
• various compressed versions of UDRW,
• CD/DVD master for export (UDTO),
• sparse disk image (UDSP), a single file rather than a bundle.

Those specify the container format; within each, there’s the usual choice of file systems, although throughout these articles it will normally be assumed that APFS will be used unless otherwise specified.

The word sparse in sparse bundle and sparse disk image doesn’t refer to APFS sparse files, but to the fact that those types of disk image can grow and diminish in size, and normally try to occupy the minimum amount of disk space. This is an unfortunate name collision.

Structure

With the exception of sparse bundles, all disk images are contained within a single file of opaque structure.

Sparse bundles consist of a single bundle folder containing:

• bands, a folder containing the contents of the disk image in band files
• info.plist and its backup copy info.bckup, containing settings including band size
• lock, an empty file
• mapped, a folder containing small data files to match all of the band files except the first
• token, an empty file.

Container size

Until this changed in Monterey (or thereabouts), non-sparse disk images had fixed container sizes. Create a UDIF read-write disk image (UDRW) of 10 GB, and the space occupied by it on disk was approximately 10 GB, whether it was empty or full. Although it remains undocumented, when stored on APFS volumes, UDRW disks can now take advantage of APFS sparse file format, and will normally only occupy the disk space required for the contents of their file system.

This is only true once the disk image has been mounted for the first time after it has been created, mounted and unmounted. To see this, create a test read-write disk image (for example, using Disk Utility) of 10 GB size. Then unmount it, and use the Finder’s Get Info command to inspect its size on disk. That will be 10 GB. Then mount the disk image again, pause a couple of seconds, unmount it, and Get Info will show its size on disk is now much smaller.

As I’ll explain in detail in a later article, this is because each time that disk image is mounted, if its internal file system is HFS+ or APFS, its contents will be trimmed, and saved to disk in sparse file format, which omits all its empty space. This only applies to read-write disk images when they’re stored in APFS file systems; copy them to HFS+ and they’ll explode to full size, as HFS+ doesn’t support the sparse file format.

Considering just the two leading types, empty sizes for a 100 GB disk image are:

• a sparse bundle is 35.4 MB empty, 53.3 GB when containing about 51 GB files, stored across 6,359 band files.
• a read-write disk image (UDRW) shrinks to 333.8 MB once stored as an empty sparse file, 53.6 GB when containing about 51 GB files, in a single file container.

Performance

Some types of disk image perform poorly, and can be very slow to write to. Recent versions of macOS have brought improvements, although some options such as encryption can still impair performance significantly. For the two leading types, when their container is stored on the internal SSD of an Apple silicon Mac, with native read and write speeds of around 6-7 GB/s:

• an initially empty unencrypted sparse bundle reads at 5.1 GB/s, and writes at 4.8 GB/s.
• an initially empty unencrypted read-write disk image (UDRW) reads at 5.3 GB/s, and writes at only 1 GB/s.

Tests were performed using my utility Stibium, across a range of 160 files of 2 MB to 2 GB size in randomised order, with macOS 15.0.1.

Key points

• Disk images consist of a file or bundle containing one or more file systems; the container and its contents are distinct.
• To access the contents of a disk image, the container is first attached, then the file system(s) within it are mounted. In the Finder, those two processes appear as a single action.
• Encrypted disk images encrypt the container, and don’t necessarily contain encrypted file systems.
• Disk images come in many different types, and can contain different file systems.
• Sparse bundles have a file and folder structure inside their bundle folder, with their data saved in band files; all other disk images are single files.
• Sparse bundles grow and shrink according to the size of files stored within them.
• In recent macOS, and on APFS, read-write disk images (UDRW) are stored in APFS sparse file format, enabling them to grow and shrink as well.
• In recent macOS, unencrypted sparse bundles have read and write performance close to that of the disk they’re stored on. Read-write disk images read at similar speeds, but write more slowly, at about 20% of read speed.

macOS supports several different disk formats, each of which has its purposes. This article explains which to choose from those you can create by formatting a disk in Sequoia. macOS also supports some other formats like NTFS for reading only, which I won’t cover here.

Disk structure

Before any file system can be formatted on a disk, the storage in the disk must be partitioned using one of three standard schemes:

• GUID Partition Map (GPT), standard for most disks and file systems in macOS;
• Master Boot Record (MBR), formerly used for MS-DOS and Windows;
• Apple Partition Map, an old format used by Macs, and worth avoiding unless you know it’s required.

Even if the whole of the disk is going have just one file system or volume, one of those is required, as it stores information about how the space on the disk is allocated.

Volumes and containers

Apart from APFS, most file systems you’re likely to use require a whole partition on the disk for each volume. For example, an HFS+ disk with two volumes is divided into two partitions, each of which contains one HFS+ volume. Because partitioning is intended to be static, that means those two volumes have fixed size, and don’t share free space between them. Once created, it’s possible to change partitioning, and Disk Utility will try to do so non-destructively, without losing any data in the volumes, but that isn’t always possible.

APFS volumes are different, and share free space within a partition, termed a container in APFS terminology. APFS containers are essentially similar to HFS+ volumes, as they’re static partitions, but APFS volumes are sized dynamically within their static container.

Thus, if you have a disk with two HFS+ volumes and two APFS volumes, that disk will have at least three partitions:

• one for each of the two HFS+ volumes,
• one as the container for the two APFS volumes, although they could instead each be given their own container.

You will see some claims that APFS volumes are more like directories or folders in HFS+, but those are confusing and should be ignored. Each APFS volume has its own file system, and dragging a file from one volume to another results in two completely separate copies of that file, using twice the storage space of one – that’s not how folders behave!

Available formats

Disk Utility version 22.7 in macOS Sequoia 15.0 can format the following file systems using a GUID Partition Map:

• APFS, not encrypted and case-insensitive
• APFS, encrypted and case-insensitive
• APFS, unencrypted and case-sensitive
• APFS, encrypted and case-sensitive
• HFS+ journalled and case-insensitive (JHFS+)
• HFS+ journalled and case-sensitive
• ExFAT
• MS-DOS (FAT32).

Using a Master Boot Record or Apple Partition Map, the following formats are available:

• HFS+ journalled and case-insensitive (JHFS+)
• HFS+ journalled and case-sensitive
• ExFAT
• MS-DOS (FAT32).

APFS is not compatible with Master Boot Record or Apple Partition Map.

The command tool diskutil additionally offers FAT, FAT12, FAT16, Free Space, and HFS+ without journalling, although those aren’t available in Disk Utility.

Note that, contrary to Disk Utility’s Help book, encrypted HFS+ formats are no longer available in Disk Utility, although with the availability of encrypted APFS formats, I can’t think why anyone would want to use encrypted HFS+. That’s because support for encryption was added later to HFS+, whereas it has been designed in from the start of APFS, and is far superior.

Which format for Macs?

The default format for disks to be accessed by Macs is now APFS, not encrypted and case-insensitive, and should be used with all Macs running Mojave and later.

Case-sensitivity can in some circumstances be important. The two situations where this is likely to be required is for the storage of Time Machine backups, and in volumes that might need to store native files from iOS or iPadOS, which use case-sensitive APFS.

Encrypted APFS is different from FileVault used on internal SSDs. However, if you enable FileVault on a macOS installation on external storage, that’s implemented as encrypted APFS. On the internal SSDs of Macs with T2 or Apple silicon chips, FileVault provides additional protection to the keys used for its hardware encryption performed in the Secure Enclave, and should always be enabled. Encrypted APFS is strongly recommended for volumes on external disks that contain private or sensitive data, such as Time Machine backups.

Thus, Time Machine backups should be made to case-sensitive encrypted or unencrypted APFS, and that’s what Time Machine will create for you.

APFS or HFS+?

APFS was designed for use primarily on SSDs rather than hard disks, and doesn’t have features intended to maintain performance when used on hard disks. Unless a volume on a hard disk is intended to store Time Machine backups, it may therefore still be preferable to use either of the supported HFS+ formats. Deciding which is better depends on how that volume will be used.

Because SSDs are largely unaffected by fragmentation of used or free space, APFS isn’t designed to minimise fragmentation, indeed some of its best features inevitably increase fragmentation. In particular, the file system metadata in APFS volumes may become badly fragmented, leading to poor performance on hard disks. Two extreme examples are boot disks and those used to store largely static media libraries.

Recent versions of macOS will happily boot from external hard disks, and despite their relatively poor transfer rates, are far from unusable. Problems come as you use that hard disk, and perform file operations in your Home folder. Over the course of a few weeks or months, fragmentation increases, particularly in file system metadata, and its performance declines.

Media libraries that are most frequently read from, and whose files undergo relatively little change, have fewer changes in their file system metadata, and may well never suffer from noticeable performance impairment. This is also true for Time Machine backups, although some users report deteriorating performance after many months or a year or two.

Time Machine in Sequoia will no longer start a new backup series on HFS+; if you try adding a disk with a single HFS+ volume on it as backup storage, it automatically converts the disk to an APFS container with a single APFS case-sensitive volume, and uses that to store its backups. However, you can still use third-party backup utilities including Carbon Copy Cloner to make backups to HFS+ volumes, although APFS is recommended now. That can have several significant disadvantages, among them:

• Snapshots can’t be made of backup storage.
• APFS special file types aren’t supported. For sparse files, this can lead to backups being substantially larger than the source files. Worse still, if you restore from a backed-up sparse file, it won’t be automatically converted back to sparse file format on APFS.
• Block copying isn’t normally supported, again making backups larger, and increasing the time required to back up.
• Where available, incremental backups may become unmanageable because of the number of files and folders.

As a general principle, both APFS and HFS+ can be backed up to APFS backup storage, while HFS+ storage is only suitable for backups from HFS+.

Which format for Windows compatibility?

Although other computers can read HFS+ and sometimes even APFS volumes, few of their users know how to access the Mac’s native file systems. If you need your storage to be accessible from other computers, one of the two supported MS-DOS/Windows formats is best.

Information given in the Disk Utility Help book is slightly misleading over the choice between FAT32 and ExFAT. FAT32 offers a maximum volume size of 2 TB, with files up to almost 4 GB each, but was primarily intended for magnetic media.

Unless the system intending to read the volume is limited to FAT32, it’s generally preferable to use ExFAT instead. That supports massive volumes and file sizes, and was optimised for use in flash memory. ExFAT is thus the more commonly encountered format for USB flash drives (thumb drives, memory sticks) and SD cards, where it’s the default format for SDXC and SDUC cards larger than 32 GB.

FAT32 and ExFAT are supported with both GUID Partition Map and Master Boot Record schemes. Unless the other computer or system is very old, prefer GUID Partition Map. Neither volume format supports encryption, so if you want to protect files you should encrypt them separately, or store them in an accessible encrypted archive format.

Summary

• For general purposes, default disk format should use a GUID Partition Map with either plain or encrypted APFS.
• Encrypted APFS should be used for volumes on external disks containing private or sensitive data. File Vault should be enabled on internal SSDs.
• New Time Machine backups can now only be made to case-sensitive APFS, either plain or encrypted.
• Hard disks with active file systems may suffer poor performance with APFS, and HFS+ with journalling may still be preferable, but it has significant limitations and disadvantages.
• Hard disks for more static use, such as for media libraries and backups, should be safe with APFS, but may eventually suffer poor performance.
• Unless there are good reasons for using FAT32, format USB flash drives, SDXC and SDUC cards that need to be used with non-Mac systems using ExFAT in a GUID Partition Map scheme.

Since its first public release seven years ago in High Sierra, APFS has changed greatly. Connect a bootable external disk with Sonoma installed to a Mac running macOS 10.13 and it won’t know what to make of it. That’s because many of the features used by APFS today didn’t exist until Catalina and Big Sur. This article explains how your Mac can cope with running such different versions of APFS, and how to avoid the problems that can arise when a Mac can start up in two or more different versions of macOS.

Fences

Disk structures, APFS and macOS fall into three main phases:

• High Sierra and Mojave, which can run 32-bit code, boot from a single integrated volume, and don’t understand Signed System Volumes (SSVs); they run APFS versions 748.x.x to 945.x.x.
• Catalina (macOS 10.15), which can’t run any 32-bit code, and boots from a group of volumes where the system is contained in its own read-only volume; it runs APFS version 1412.x.x.
• Big Sur and later, which can’t run any 32-bit code, and boot from an SSV that’s a specially sealed snapshot on the System volume; they run APFS version 1677.x.x and later.

Fuller and finer details of the changes with different versions of macOS are given in the Appendix at the end.

If you need your Mac to run more than one version of macOS, it’s easiest and most compatible if the versions installed come from only one of those phases. Two phases are more of a challenge, and all three needs great care to ensure that one version doesn’t damage the file systems of another.

When you do need to run macOS from two or more phases, the cleanest and safest way is to only mount disks and volumes from one phase at a time. For example, when running Mojave, if you unmount disks and volumes for all later versions of macOS, then you won’t see any notifications warning you of Incompatible Disk. This disk uses features that are not supported on this version of macOS. Unfortunately, unless all your boot systems are on external disks, this isn’t easy to achieve.

Warnings

Generally speaking, APFS tools including those run by Disk Utility (including fsck_apfs, used by First Aid) are backward-compatible, but may not be as reliable when a tool from an older version of macOS is run on a newer version.

First Aid and fsck_apfs normally report versions of APFS tools used on the volumes and containers they’re checking. These draw attention to any potential for incompatibilities, such as:
The volume [volume name] was formatted by diskmanagementd (1412.141.1) and last modified by apfs_kext (945.250.134).
telling you that volume was created by macOS 10.15, and last changed by macOS 10.14.

Other messages you might see include warnings like: warning: container has been mounted by APFS version 2236.141.1, which is newer than 1412.141.3.7.2, which is less helpful.

If you’re going to run multiple versions of macOS on the same Mac, you’ll have to get used to those. For reference, APFS versions decode to macOS versions as:

• 249.x.x is the beta release from macOS 10.12 Sierra
• 748.x.x is 10.13 High Sierra
• 945.x.x is 10.14 Mojave
• 1412.x.x is 10.15 Catalina
• 1677.x.x is 11 Big Sur
• 1933.x.x is 12 Monterey up to 12.2
• 1934.x.x is 12.3 Monterey and later
• 2142.x.x is 13 Ventura
• 2235.x.x is 14 Sonoma up to 14.3
• 2236.x.x is 14.4 Sonoma and later
• 2311.x.x and later is macOS 15 Sequoia beta.

Dangers

To minimise the risk of any problems arising, any manipulation of the file system should be performed by Disk Utility, the diskutil command tool or others, for the same or later version of macOS. Thus, if you have Mojave and Big Sur installed, you could use tools from either to maintain Mojave file systems, but should only use those for Big Sur when maintaining Big Sur’s file systems.

This becomes more difficult when file system maintenance needs to be performed in Recovery mode. Once the Mac has started up in Recovery, check the version of macOS before opening Disk Utility, using fsck_apfs, diskutil or anything similar.

This is one situation where versions of macOS with an SSV can become tricky, because of their different associations with Recovery systems. On Apple silicon Macs, Big Sur doesn’t use a paired Recovery volume, whereas Monterey and later do. To be confident that the Mac starts up in the correct version of Recovery, it should have been running that version normally before you start it up in Recovery. Once in Recovery, check the version of macOS before proceeding to work with its file systems.

Appendix: APFS and macOS version details

APFS major version numbers change with major version of macOS:

• macOS 10.12 has APFS version 0.3 or 249.x.x, which shouldn’t be used at all.
• 10.13 has 748.x.x, which doesn’t support Fusion Drives, but has basic support for volume roles.
• 10.14 has 945.x.x, the first version to support Fusion Drives.
• 10.15 has 1412.x.x, the first version to support the multi-volume boot group, and introduces extended support for volume roles, including Data, Backup and Prelogin.
• 11 has 1677.x.x, the first version to support the SSV, and Apple silicon. On M1 Macs, it doesn’t support the paired Recovery volume, though.
• 12 has 1933.x.x until 12.2, thereafter 1934.x.x, which support the paired Recovery volume on Apple silicon.
• 13 has 2142.x.x, and is probably the first to support trimming of UDRW disk images and their storage as sparse files.
• 14 has 2235.x.x, until 14.3, thereafter 2236.x.x.

Minor version numbers increment according to the minor version of macOS, and patch numbers wander without pattern.