When I published A Correction to Andrew Cunningham’s Claim in Ars Technica on Cyberpunk 2077’s Mac Install Size, I referenced two Apple apps that downloaded additional content, as a counter to Cunningham’s assertion that doing so was prohibited. One was Xcode, which I stated was “a 12.5GB initial install, with optional SDKs, simulators, and tools taking up to 41GB.”

A Friend Who Would Know™ got in touch with me with a fact check of my size assertion, noting that Xcode was between 4.06GB and 5.31GB on disk (a recent Apple silicon-only beta version being the smallest and the current Mac App Store Universal version the largest).

He was absolutely right: The Mac App Store install for which I reported “12.5GB” shows only “5.31 GB on disk” in Finder’s Get Info window.

This is a long-standing quirk of how Finder displays file sizes, and the benefits of several features of APFS (🛎️) working together to reduce on-disk file sizes.

Finder reports three numbers for a file’s size:

1. A human-readable size (“12.48GB” here).
2. The number of bytes for the file (“12,476,896,275 bytes” in this case).
3. The amount of actual space that file consumes on disk (“5.31 GB on disk”).

I reported the human-readable size (rounded), because that’s what I suspect most people will consider the “file size”: it’s also what’s displayed in the Size column in Finder.

However, if you’re concerned about “disk space,” it’s perfectly reasonable to consider just the “on disk” size, as that’s the actual free space you would theoretically need for Xcode.

(I’m ignoring here the space needed to download, decompress, and install the app.)

However, I ran a couple of tests to see if my assumption that the “on disk” size is the amount of free space I’d need was valid. I created four APFS-formatted disk images using Disk Utility: 6GB (5.77GB free), 7GB (6.77GB free), 13GB (12.75GB free), and 15GB (14.75GB free). I then tried copying the “5.31 GB on disk” Xcode.app to each one. The results were both exactly and not at all what I expected:

• 6GB, 7GB images: Copying failed with an error: The item “Xcode.app” can’t be copied because there isn’t enough free space.
• 13GB, 15GB images: Copying completed, after which the 13GB disk image showed 7.1GB free, while the 15GB image showed 9.08GB free.

The math ain’t mathing!

I expected the 6GB and 7GB results, despite the “on disk” size, because I suspected that number is the result of some APFS behind-the-scenes magic: It would still need the number of bytes to be free to complete the copy.

The successful copy to the 13GB and 15GB images was also not a surprise. What did shock me was the amount of free space reported after the copy. How does a 13GB disk image, with 12.75GB free to start, end up with 7.1GB free after copying a 12.48GB file?!

(To further amuse myself, I then duplicated the copied app on the images several times. Each copy took up almost no additional space—an extra 0.15GB in total for three copies.)

What kind of APFS witchcraft is this?

The (short) answer is likely some combination of clones, sparse files, hard links, and maybe transparent compression—all APFS features. I won’t pretend to be capable of explaining them here, but if you’re interested in learning a bit about APFS, About Apple File System has an introduction (and Apple File System Reference has exhaustive details that no mere mortal should be reading).