Adding your own custom icons to files and folders goes back a long way, to Classic Mac OS where it was widespread. With all the changes brought in recent versions of macOS, particularly Sequoia’s changes to Quick Look, this article explains how you can still replace standard icons with your own.

Add a custom icon

You can copy an icon already used by an app, file or folder on your Mac by selecting it and using the Finder’s Get Info command. In that dialog, select the small icon at the top left of the window, and copy it.

If you want to modify or design your own icons, a good graphics editor like GraphicConverter is fine. Work with a PNG image with a transparent background and dimensions of 1024 x 1024 pixels. When it’s ready, select all and copy it.

To add your custom icon to an app, file or folder, select it in the Finder, open the Get Info dialog, select its current icon at the top left, and paste in your replacement.

Where it doesn’t work

There are some items that you can’t add a custom icon to. Any app, file or folder in the Signed System Volume can’t be modified in any way, and those in folders where you don’t have write access won’t work either. If you really wanted to display one of those with a custom icon, the only way to do that is to create an alias, and paste your replacement icon into Get Info for that alias.

How it works

When you add a custom icon to a file, the icon is converted into a traditional resource of icns type, and written to an extended attribute of type com.apple.ResourceFork attached to that file. That xattr is the modern equivalent of the old resource fork used in Classic Mac OS. It’s also surprisingly large, typically around 330 KB, which can bring its own problems as described later.

When you add a custom icon to a folder, including one that’s enclosing a bundle like an app or RTFD document, it isn’t added as an extended attribute to the folder, but is added to a hidden file named Icon? (the last character isn’t really a ? but is actually Carriage Return, UTF-8 0D) inside that folder. Normally, icons to be displayed for an app are saved as an AppIcon.icns file inside the Resources folder within the app bundle, but modifying that could break the app’s signature. A custom icon dodges that by being saved outside the bundle itself, and in an extended attribute rather than as data.

Aliases are complicated

Add a custom icon to a folder, then make a Finder alias to it. What you’ll then see is a muddle.

In the Get Info dialog, the Preview shows the custom icon, but the icon displayed in the Finder is the default folder with an alias arrow superimposed. To get the alias to display your custom icon, you have to Get Info on the alias and paste that icon into the top left.

This rule, that the Preview shows the icon associated with the original, while the regular icon shown is that for the alias itself, extends to bundled apps. As you can’t add a custom icon to a bundled app, because its bundle can’t be changed in any way, one workaround might be to create an alias to the app and add your custom icon to that alias.

What then happens is that your alias displays its custom icon, but the Preview shown is the original app icon that you can’t change.

The biggest problem with attaching custom icons to aliases comes when the alias needs to be remade, for example by my app Alisma. The remade alias is then likely to lose its custom icon, which you’ll have to paste in again.

iCloud folders are complicated too

Just when you think you’ve understood how custom icons work, you try using them in iCloud Drive, and discover that there are some further subtleties.

iCloud Drive doesn’t like storing Icon? files in the cloud, and even if it would do so, it couldn’t upload the crucial com.apple.ResourceFork extended attribute, as iCloud doesn’t like them. Furthermore, the standard custom folder icons that you see in iCloud Drive aren’t created by the same mechanism, and can’t be overruled by your own icons.

The end result is that, while you can add custom icons to plain folders in iCloud Drive, the only client that will see them is the Mac that customised them in the first place, as that’s the one with the Icon? file and its extended attribute. Other Macs and devices won’t see the custom icon, unless of course you add it to the same folder on them. The same goes for custom icons on files.

In the recent past, custom icons have been unreliable in iCloud Drive. That was because, when the folder was evicted from local storage, the hidden Icon? file was sometimes lost, and couldn’t be replaced when the contents of the folder were downloaded again. That appears to have been fixed recently, and they should now be more stable in macOS Sequoia.

Happy customising!

In the year that we celebrated the fortieth birthday of the original 128K Mac, Apple has ensured we’ve got plenty more to remember in the future. Just as we were starting to get to grips with its third cycle of Apple silicon Macs, it leaped into the start of the fourth, in the first M4 models. We’ve also just about survived the annual purgative macOS upgrade, and even updated the firmware in our Magic Keyboards.

For once, the release of Macs featuring the next family in the M-series was heralded by their appearance in iPads in May. By that stage I had just about worked out what had changed in the CPU cores of the M3 from the previous November. Perhaps my most lasting impression is that code running in a virtual machine on an M3 host is often faster than running native on an M1 from four years ago.

Apple then delivered the smallest Mac ever in the Mac mini, a product line that didn’t even have time for an M3 version. Perhaps inevitably, I and a great many others recognised a new classic in the making, and my Mac mini M4 Pro has displaced my Mac Studio M1 Max from its connection to my Studio Display since it arrived on 8 November. Since then I’ve been stealing a little time to look inside its CPU core management, and have been surprised at how different it is from all the previous Apple silicon Macs I’ve examined.

I’ve also been delighted at how many using older Macs, some as far back as High Sierra, have decided the time is right to migrate to an M4. Leaping forward through all the changes in macOS over those seven hectic years isn’t straightforward, and learning that every one of your apps needs to be replaced must be disquieting. Those of us who have endured the annual pain of architectural changes brought by each new version of macOS can see how concentrating all that into a single migration is going to be intense agony. It’s like having your blisters treated with tincture of benzoin and its couple of minutes of excruciating pain, compared with the prolonged discomfort of leaving the blisters to heal naturally.

While Apple distracted almost everyone with its delayed introduction of AI tools, macOS Sequoia brought plenty of new and changed features that have had greater immediate impact.

Virtualisation of macOS on Apple silicon Macs has for too long been almost wonderful. Sequoia has nudged it slightly closer, but left it even more tantalisingly close, with the addition of limited support for what’s now known as Apple Account. The most obvious missing feature in macOS VMs has been support for App Store apps. Given Apple’s emphasis on their value, it’s extraordinary that VMs can enjoy good iCloud support, but still can’t run any third-party App Store apps. The underlying reason is most likely the authorisation scheme for the use of App Store apps, a tragic example of Apple’s business model thwarting its engineering aims. As far as I can tell, VMs aren’t eligible to use AI either, although for some that may be a blessing.

Sequoia lays the foundations and builds the first storey of a password manager that deserves further development. Its success is going to depend on whether Apple can integrate a modern solution for the login and other traditional keychains, a problem that the Keychain app currently ducks and leaves to Keychain Access, but hiding that still essential utility away in CoreServices won’t make it go away.

iCloud Drive has at last gained the ability to ‘pin’ files and folders to prevent them from being evicted from local storage. However, what at first sight appeared perfect paled when we discovered its idiosyncratic human interface that behaves like nothing else in the Finder, if not the earth. Hopefully an engineer will be along later next year to improve that.

In other ways Sequoia wasn’t so marvellous. One of its smaller changes that has rightly offended many has been the removal of support for third-party qlgenerators, responsible for QuickLook thumbnails and previews of custom document types. Apple had deprecated them way back in Catalina, so we had been warned, but quite a few good apps have lost QuickLook features as their developers haven’t yet implemented the App Extensions required to replace their now non-functional qlgenerators.

There has been a great deal more going on underneath the interface of macOS. As I’ve already explained in more detail, 2024 has been the year of XProtect, not only for its new update mechanism, but for Apple’s heavy assaults on malware including Adload, the subject of a hefty campaign of new detection signatures back in April.

In May, following unsubstantiated reports of the reappearance of old files, there was speculation as to the effectiveness of one of macOS’s more recent boons, Erase All Content and Settings, or EACAS. As so often happens, the rumours failed to stand up to careful scrutiny, and many former owners of Macs breathed easier that they hadn’t passed on all their personal data when they disposed of their previous Macs.

Notable by their absence over the whole of the year have been RSRs, the Rapid Security Responses we had been led to believe would spare us urgent macOS security updates. Although they may have fallen out of favour, the cryptexes they rely on have proved more useful in other ways.

Finally, the fortieth anniversary of the 128K Mac has been marked in another nearly unique event, a firmware update for Apple’s Bluetooth Magic Keyboards that was so stealthy most of us aren’t aware that our keyboards were updated, or maybe they weren’t and it was all a dream. And I managed to get to the end of this review of 2024 without looking in detail at AI. I’m sure there’ll be time for that next year.

I wish you all a peaceful and prosperous New Year.

Finder tags are a popular way to add accessible metadata to files and folders in macOS, with attractive properties:

• Their associated colour tags are easily seen and instantly recognisable.
• Each colour can be associated with one or more text labels.
• The Finder can display tagged items conveniently.
• Tags propagate through iCloud Drive, and can be used fully in iOS and iPadOS.
• Tags are generally preserved within macOS, for example when copying or moving items between volumes.
• Tags are searchable using Spotlight, as their text labels are indexed.

I have explained their use in this article.

Their principle limitation is that they’re limited to 7 colours, together with no colour. That allows you to assign multiple text labels to each colour, but the results of that can be confusing given that Finder display and search are based on their text labels not colours.

Implementation

Finder tags are implemented as extended attributes (xattr), currently of type com.apple.metadata:_kMDItemUserTags. However, historically they can also be implemented alongside other Finder information in com.apple.FinderInfo xattrs.

com.apple.metadata:_kMDItemUserTags xattrs consist of a binary property list containing brief UTF-8 text. This is an NSArray consisting of Strings, each containing a text label, followed by the newline character, followed by the colour number (0-7). The array can be empty. Obviously, labels can’t include the newline character; although they can include the colon character :, that has been reported as causing problems in some versions of macOS and is worth avoiding.

Colour numbers used are:

• none, 0
• grey, 1
• green, 2
• purple, 3
• blue, 4
• yellow, 5
• red, 6
• orange, 7.

Thus a tag name might read Red\n6, or Orange\n7 Green\n2 for two colours, where \n represents the newline character 0a.

When the Finder writes a tag xattr to an item, it also adds a null com.apple.FinderInfo xattr of 32 bytes length, if a xattr of that type isn’t already present.

com.apple.FinderInfo xattrs can be used to store a single colour tag without a text label, although this shouldn’t be encountered any more. When they do, a single byte is set in their fixed length of 32 bytes, the kColor flag just to the right of the Hide extension flag. For instance, <00000000 00000000 00040000 00000000 00000000 00000000 00000000 00000000> sets the Green tag. This scheme uses a different encoding for colour flag values:

• none = 00, 01
• grey = 02, 03
• green = 04, 05
• purple = 06, 07
• blue = 08, 09
• yellow = 0A, 0B
• red = 0C, 0D
• orange = 0E, 0F.

Basic checks

With a selection of tagged items, first verify the colours and text labels are shown correctly in the Finder’s Get Info dialog, and match those against com.apple.metadata:_kMDItemUserTags xattrs inspected using xattred‘s drag and drop interface. Also check com.apple.FinderInfo xattrs, although they shouldn’t have their kColor flag set.

Check tagged items both locally and in iCloud Drive. Note that tags should be preserved even when that file has been evicted from local storage to iCloud, as xattrs are stored locally and retained on dataless files. Tags should also be displayed in apps that support them, and in File Open and Save dialogs.

Problems with these basic checks should make you suspect file system errors in volumes affected. Run Disk Utility’s First Aid on that volume and perform necessary repairs. Although they should be shown in some other file systems, Finder tags are best-supported by HFS+ and APFS volumes and may have limitations in other file systems.

iCloud Drive syncing

Test this with:

• In the Finder, open a user folder in iCloud Drive. Select a file there, and add a Finder tag to it using the contextual menu.
• That should result in an immediate and brief sync up to iCloud, to copy that tag up.
• Check that this change syncs across other Macs and devices connected to the same Apple Account.
• If necessary, add the tag at a known clock time and use that to inspect iCloud systems in the log, using Mints or Cirrus.

Failure to sync the changed tag information with iCloud indicates a problem in syncing with iCloud, and requires separate diagnosis.

Spotlight search

Before looking at search for tags, first confirm normal Spotlight indexing and search function using Mints. If those tests don’t work correctly for search of file contents, address those problems first before assessing tags.

The single most common reason for search failures is that the item being searched for is in a location excluded either from indexing or from returning search results. Check Spotlight or Siri & Spotlight settings for the following:

• That item’s category isn’t excluded from appearing in Spotlight search results. For example, if the Images item in the list there isn’t ticked, then images will still be indexed, but Spotlight won’t return any images in its search results. Unless you have a good reason, the simplest setting here is for all boxes to be ticked.
• That item’s path isn’t within any of the locations listed in Search Privacy…, as those aren’t indexed at all.

There have been additional methods for excluding specific items from being indexed by Spotlight, of which two are currently effective:

• appending the extension .noindex to the folder name (this previously worked using .no_index instead);
• making the folder invisible to the Finder by prefixing a dot ‘.’ to its name;
• putting an empty file named .metadata_never_index inside the folder; that no longer works in recent macOS.

Check that the items you expect Spotlight to find aren’t subject to any of those. Details of those items not synced by iCloud Drive are given in this article.

In addition to those excluded locations, Sequoia (and possibly other recent versions of macOS) generally excludes folders and files within either of the two user-writable Library folders, /Library and ~/Library. Limited indexing is performed within the Application Support folder, but that doesn’t appear to include tags. Although iCloud Drive as a whole is shown as being inside ~/Library, it’s indexed differently, as given above, and that should also include app-specific folders in iCloud Drive.

Before even considering rebuilding a volume’s Spotlight indexes, check whether Spotlight correctly indexes test files created using Mints, when you add tags to them. When tags are added, you may be able to see a short burst of mdworker activity in Activity Monitor, and it should be recorded in the log, as checked using Mints. Full details of diagnosing and fixing problems with Spotlight search are given in this article.

Step summary

1. Verify tags as xattrs both locally and in iCloud Drive, using xattred.
2. Verify syncing in iCloud Drive using Mints or Cirrus.
3. Check Spotlight search is working correctly for other contents, using Mints.
4. Verify tagged items are in a path that isn’t excluded from indexing, and their category is set to return search results, in System Settings.
5. Diagnose any underlying Spotlight problems using Mints.