If you’ve ever installed Xcode via the Mac App Store, you know it can take an hour to install. The reason is not due to its size but the large number of individual files. What if it didn’t have so many small files? Could optimizations made here apply to other apps as well?

Overview

The idea is simple: instead of storing apps as a constellation of individual files, instead store a disk image with its own filesystem. The idea isn’t new and has been used elsewhere and so much of what I’m going to outline here is what one familiar with the idea might expect. So instead of an app being a directory, its current representation, the contents of that directory exist in a read-only filesytem stored in a disk image. Then the app is really a single file, the image itself. Accessing contents within the app is simply traversing the filesystem within the image.

It’s no secret that Apple’s Time Machine backup solution is clunky at best. For those who are unaware, it backs up a Mac to an HFS+ filesystem using directory hard links. The biggest problem with this is that HFS+ was an old filesystem when Time Machine was first designed and it’s gotten even older since. These days Apple uses APFS as their filesystem on computers and iOS devices but the Time Machine backup still uses the fragile HFS+ filesystem for its backups. If you select a backup target that’s not HFS+, such as a network share, it creates a sparse disk image there and creates an HFS+ filesystem in that image. I question whether there was a better way. There is but I wouldn’t expect Apple to bother actually implementing it because, well, they don’t actually seem to care about quality anymore.