For much of the last week, the UK has been enjoying its first really warm and fine spell of weather this year. Although we can be assured that there is worse to come before the summer proper, it has reminded us that the winter is behind us. As is, we hope, the Mac’s winter – that long period in which it looked as if Apple didn’t care for, or understand, the needs of the ‘pro’ user, and seemed content to offer us old and long-jaded models.

Apple’s exceptionally open session with a selection of the press revealed that there will be new iMacs coming this year, that Apple recognises that there are many high-end iMac users who want ‘pro’ options, and most of all that Mac hardware development hasn’t stopped. We will have to wait until next year for a new Mac Pro, which is neither encouraging nor demonstrative of the commitment that Apple could make, and the mini line has a future, although that is rather more vague.

We also expect that WWDC, in early June, will bring the announcement of macOS 10.13, with its salient feature of a new file system, APFS.

It’s hard to overstate the importance of APFS to the future of macOS and iOS hardware. Although very few users ever get that close to the file system, it is of central importance in determining how computers and devices ‘feel’, how you can interact with them, and their performance. Apple has been looking for a suitable replacement for the current Mac Extended file system, HFS+, for many years. At one time, it looked to have settled on Sun’s ZFS, but got cold feet.

File system gurus will happily debate the ins and outs of ZFS, APFS, and other potential candidates, but for users Apple’s choice brings several immediate benefits. One is sophisticated integral support for encryption of whole disks and selected files and folders, which will make FileVault 3 far better and more widely used. Its ability to make snapshots will radically transform Time Machine backups, which are currently based on an ingenious kludge. APFS should also perform much better, particularly on solid-state (SSD) and future fast storage systems.

APFS was needed for iOS, watchOS, and tvOS devices, on which it has already rolled out with the last update. But it is most important for macOS, where it will have to cope with a rich range of storage systems, millions of files, often badly-behaved third-party apps, and client-server systems.

Now that APFS is mature enough to install and use on hundreds of millions of iOS devices, I have been looking at some aspects of its use in macOS over the last week. As you may have read here and elsewhere, current impressions are mixed. It seems to be doing well on iPhones and iPads, but I and others have concerns over its use on our Macs in the near future.

In their day, HFS then HFS+ have been at the leading edge of popular ‘user’ file systems. The original Mac stood out for its ability to use plain-language file and folder names, at a time when most computers still coped with rigid systems fixed to eight upper-case characters before a three-character extension, the old ‘8.3’ standard.

For all its flexibility, the variant of HFS+ to which users were most commonly exposed, with Classic Mac OS and OS X, has been quietly restrictive. Although a case-sensitive variant has been available, and was used for iOS before 10.3 was released on 27 March 2017, the variant of HFS+ used on almost every Mac has been case-insensitive, and has never allowed you to place two items named File and file in the same folder.

It has had another almost hidden restriction which has only affected those who use filenames which include accents, like café, or non-Roman character sets. Many of those Unicode characters have more than one possible encoding, which normally appear indistiguishable. In the case of café, it can also be encoded as café. (By a quirk of fate, the font used for this blog shows some minor differences between the e-acute letters; the great majority of fonts show identical characters.)

To spare the user from quirks resulting from these multiple representations, HFS+ has performed normalisation: if you enter either of those words for a file or folder name, HFS+ silently changes the e-acute character to one common form, determined by an elaborate set of rules (Unicode Normalised Form D). This ensure more predictable behaviour for the user.

Performing this normalisation on every file and folder name brings with it a significant impact on performance, and in many circumstances is not really necessary at all. Some modern file systems, such as ZFS, gain performance improvements by normalising only where they absolutely have to, and that is Apple’s design choice for APFS. At the file system level, APFS therefore does not normalise file or folder names, just stores them exactly as they are formed.

If Apple were to unleash the case-sensitive variant of APFS, which is also normalisation-sensitive and does not normalise file or folder names, on macOS, the impact on users would be great, and decidedly negative. Case-sensitivity would break many macOS apps (just as it already does if you use the case-sensitive variant of HFS+), but could make the Finder easier to use in some respects. At present, on HFS+, if you try to copy the file named This into a folder containing a file already named this – with the only difference being that of case – macOS complains that the names are identical, and asks if you want to replace one with the other. Case-sensitivity would end that limitation.

We can see differences in case, so although this is an unnatural restriction, we tolerate it, and learn to avoid such case conflicts.

Normalisation is a different issue, though. Apple has decided to make the case-insensitive variant of APFS normalisation-insensitive too. That means that it does not permit two items in a folder which differ only in characters which could normalise to the same character. So while APFS itself can happily cope with café and café in the same folder, this variant recognises that they appear the same and stops you from putting them together.

That is an engineering solution to a usability problem, sticking to the principle that APFS does not normalise. It may help APFS to retain performance improvements in formal testing, but it doesn’t look at the complete solution. Where the file system doesn’t normalise, apps and command tools will then have to perform normalisation, and take the performance hit. This prevents apps from achieving the same performance that might be expected from more fundamental benchmarking.

That is because, even though the file system may not care whether a file is named café or café, apps and tools have to. When you perform a file search, for instance, you would be very upset if it only found one of those files and not the other, given that their names appear identical, so you may not even be aware that they are encoded differently. So every comparison, search, and sort on file or folder names will have to operate on normalised names. As APFS does not store those, in order to improve performance, the performance of the comparison, search, or sorting operations will suffer as they bear the brunt of normalisation.

No doubt file system engineers argue that it is not the job of the file system to normalise names. So too the app developers could pass the blame to Unicode, which should never have permitted visibly indistiguishable characters to be assigned different codes. The user – who has no one to blame – just has to get on with it, wondering why this shiny new file system doesn’t actually feel much different. And why their apps seem to have such odd problems with certain filenames.

macOS 10.13 and new Mac hardware give us more than just the summer to look forward to. I just hope that they each live up to our expectations.