On 27 March 2017, Apple made one of its biggest corporate gambles. When it rolled out iOS 10.3 that day, the installer silently converted the storage in each iPhone and iPad to the first release of Apple’s new file system, APFS. Had a significant percentage of conversions gone wrong, Apple would have had a disaster on its hands, particularly as it didn’t admit to doing this until WWDC just over two months later, when it announced that APFS was coming to macOS 10.13 High Sierra that September.
macOS Sierra already had a pre-release version for those who wanted to preview it. That ended its life in 10.12.6 as version 0.3, or, expressed in subsequent numbering, 249.7.6. As we discovered when we upgraded to High Sierra, though, that was a far cry from what was to come, and never achieved any useful level of compatibility with it either.
After a promising period in beta-release, Apple discovered fundamental problems in support for its popular Fusion Drives. The first release version, 748.1.46, which shipped with High Sierra 10.13, therefore suddenly dropped support for those, and went ahead and converted startup volumes on SSDs and hard disks. Snapshots were still wobbly, and it quickly became clear that APFS wasn’t going to perform well on rotating disks.
High Sierra had a stormy early release history, marred by a series of security gaffes. Vulnerabilities were fixed in the Supplemental Update released less than two weeks after 10.13, which included changes to bring APFS to version 748.1.47. Snapshots were improved in 10.13.1 on 31 October, in APFS 748.21.6. Many of us anticipated that the problems with Fusion Drives would be fixed quickly, but APFS reached version 748.51.0 in 10.13.4 on 29 March 2018, and didn’t change version or capabilities until the release of Mojave that September. Another problem which marred the introduction of APFS to all platforms was the refusal during beta-testing to incorporate Unicode normalisation; this had to be resolved in release versions of macOS 10.13 and iOS 10, as explained here and here, although even now problems occur occasionally.
On 24 September 2018, Apple released Mojave 10.14, at last with support for its Fusion Drives. This was also the time that the first version of the Apple File System Reference became available. Although a long and detailed document, developers quickly realised how incomplete it was, in spite of the long delay in its publication. At last third-party file system developers had some hard information to work with. Users began to think that the first third-party disk maintenance and repair tools were now imminent.
By 22 July 2019, when 10.14.6 was released to end Mojave’s cycle and Apple’s last 32-bit support, APFS had reached the dizzying version of 945.275.7, making it seem far more mature than its tools felt. Exceptionally, Mojave’s release of APFS is the only one which has continued to be patched when it went into security-only maintenance. Since 10.14.6, Apple has updated it again in Security Update 2 (945.275.8), and by Security Update 2020-005 (945.275.9).
Catalina brought major changes to APFS, with the use of expanded volume roles to form System Volume Groups, and we’ve all come to live with separate firmlinked System and Data volumes ever since. macOS 10.15 came with APFS version 1412.11.7, and by 10.15.5 had reached 1412.120.2, which fixed a serious bug preventing the transfer of very large amounts of data to RAID volumes. At about that time, Apple released the current version of the Apple File System Reference, which encouraged users’ expectations that third-party tools were just round the corner, while confirming to developers that Apple had no intention of releasing complete documentation for APFS.
Further major changes came with Big Sur 11.0.1 when it was released on 12 November 2020. For the first time, the System volume was signed, sealed, and booted as a snapshot. This was also the first release of macOS to support making Time Machine backups to APFS volumes, and to support Apple Silicon Macs. These arrived in APFS version 1677.50.1, and followed by fixing a vulnerability in 1677.81.1 released in macOS 11.2. The pace of change slowed towards the end of Big Sur’s time in the limelight: 11.5 came with APFS version 1677.141.1, and 11.6 with 1677.141.2, if that’s anything to go by.
The first full release of Monterey came with APFS 1933.41.2, which had gained support for a new range of M1 series models, but otherwise shouldn’t have undergone the same major changes that came with previous major new versions of macOS. What is unusual, though, is its version numbering. As I show below, APFS has consistently stuck to the same major version through each macOS cycle, but that has recently been broken in Monterey. While macOS 12.2 featured APFS 1933.80.3, 12.3 has 1934.101.3, although there don’t appear to have been any changes warranting that major version increment. Could it have been a clerical error, or has there been a big change which none of us has spotted?
It’s dangerous to read too much into changes in version numbers, as different engineering teams use them very differently. However, APFS version numbers can be important, as they’re referred to in the file system and may be quoted in terms of which version created a given container or volume, and which last modified it.
APFS major version numbers change with major version of macOS:
- macOS 10.12 has APFS version 0.3 or 249.x.x
- 10.13 has 748.x.x
- 10.14 has 945.x.x
- 10.15 has 1412.x.x
- 11 has 1677.x.x
- 12 has 1933.x.x until 12.2, thereafter 1934.x.x.
Minor version numbers increment according to the minor version of macOS, and patch numbers wander without pattern:
- macOS 10.13 went through 748.1.46 (10.13) to 748.51.0 (10.13.4 and later)
- 10.14 went from 945.200.129 (10.14) to 945.275.9 (10.14.6 with SU 2020-005)
- 10.15 went from 1412.11.7 (10.15) to 1412.141.1 (10.15.6 and .7)
- 11 went from 1677.50.1 (11.0.1) to 1677.141.2 (11.6)
- 12 started on 1933.41.2 (12.0.1), then to 1933.61.1 (12.1), 1933.80.3 (12.2), and to 1934.101.3 (12.3).
Changing version numbers thus aren’t any indication of the scope or magnitude of changes made to APFS. As Apple seldom provides any information on changes made to APFS, it’s anyone’s guess as to what is going on.
Thanks to Michael Tsai for twisting my arm and making me mention early normalisation problems.