The Locked or Immutable flag is one of the most underused and readily accessible features in macOS. It can help you avoid deleting important files, and as I’ll show later can form the basis of your own lightweight version management system. However, this all depends on you keeping it well clear of iCloud Drive, which unaccountably can’t cope with it.

Use

You’ll already be aware that you can lock files in the Finder’s Get Info dialog.

You can also lock an open file inside an app. Click on the down arrow to the right of its name in the title bar to see this pane, then click on the padlock to lock that file.

Sequoia and older versions of macOS show a Locked checkbox rather than a padlock.

In Terminal, use the chflags command in the form
chflags uchg filename
to set the user Immutable flag, the same thing as the Finder lock, and use
chflags nouchg filename
to unlock it.

Terminal also supports a second flag schg for the system immutable flag, which can only be set or cleared by the super-user, so isn’t recommended for general use. You can check these flags using ls -lO, and full details of this and other flags are given in man chflags.

Effect

When locked or immutable, you can still delete a file by dragging it to the Trash, but when you do so, the Finder warns you of the presence of the flag.

If you press ahead, you get no second chance when you empty the trash, though, as the locked file will then be deleted immediately.

Retention

The Immutable flag is stored in the file’s attributes, in the bsd_flags value in the file’s inode. It’s therefore generally preserved in local file operations, including

• moving the file within a volume,
• duplicating or copying the file within a volume,
• copying the file to a different local volume,

except with iCloud Drive.

iCloud Drive

iCloud Drive (through the FileProvider framework) doesn’t preserve the Immutable flag as you would have expected, given that it’s a file attribute rather than an extended attribute. Copying an immutable file to an iCloud Drive folder unlocks the file immediately. As if to compensate for this deviant behaviour, the file will be copied to iCloud Drive rather than moved, so leaving the locked original where it is. This is even more confusing as this behaviour is propagated to all other files being moved at the same time. If you move ten files, one of which is locked, all ten are copied rather than moved; if none are locked, then the group is moved rather than copied. This is so bizarre that it can only be a bug.

If you lock the file when it’s in iCloud Drive, the lock isn’t synced through iCloud, so that file isn’t locked on other Macs sharing the same iCloud Drive folder, although it still behaves as expected on the Mac that copied it to iCloud Drive, and will trigger a warning if moved to the Trash, but only on that Mac. Those other Macs can delete that file without any warning of it being locked, indeed they can’t even see that it’s locked on the other Mac.

Locked files in iCloud Drive when operating in non-replicating mode (with Optimise Mac Storage enabled) can’t be evicted from local storage, as that results in the error Unable to Remove Download, Resource busy. They can, though, be pinned locally with the Keep Downloaded setting.

FileProvider doesn’t yet appear to cope with locked files in any consistent way. Given how long Macs have used BSD flags in their file systems, that’s an extraordinary shortcoming.

Versioning with locking

You can use locking and clone files in a lightweight versioning system that achieves good space economy. To do this:

1. Save the first version of the document, lock it using its titlebar, and close the window.
2. In the Finder, duplicate that locked first version, unlock the duplicate and edit its name appropriately.
3. Open that new version of the document (a clone file), edit it until you want to save a new version, then return to 1 above, and repeat.

Note that using Save As to create a new version doesn’t result in a clone file, and the only alternative to protecting old versions is to make them read-only, as does Versatility.

Documentation

Apple’s account
man chflags

How would you cope if you started your Mac up to find every datestamp on every file had been set to 1 January 1970 at 00:00? Or that every Finder Tag had vanished? What if all the Exif information for your images had been wiped out? Metadata like those aren’t optional extras we can afford to lose, although other metadata, like Finder Info and the URL from which a file was downloaded, are more ephemeral.

Xattr flags

Back in 2013, when iCloud was just two years old, Apple’s engineers implemented a scheme to determine how metadata stored as extended attributes (xattrs) should be copied, to take into account its permanence. This was important at that time to ensure only the right xattrs were preserved when files were stored in iCloud Drive. They did this by adding flags to the xattr’s name to indicate which actions should result in preservation of that type of xattr, and the metadata it contains.

Apple provides an extensive suite of xattr types to store metadata such as author names, keywords and comments, whose names all start with com.apple.metadata:. These are matched by corresponding metadata attribute keys, for example the xattr com.apple.metadata:kMDItemKeywords bears the metadata content accessed by the key kMDItemKeywords. Rather than appending flags to them all, this scheme laid down a table of default flags to be applied.

Being exemplary engineers, this was all detailed in the source code for copyfile, which is also open source. However, as this was just after Apple stopped creating much of its technical documentation, and little has ever been published about iCloud Drive, that’s as far as that information went.

For iCloud Drive, the relevant flag is S, XATTR_FLAG_SYNCABLE, defined as “This indicates that the extended attribute should be copied when the file is synced on services like iCloud Drive. Sync services may enforce additional restrictions on the acceptable size and number of extended attributes.”

Default flags set for xattr types com.apple.metadata:* (except for five of the less used types) are PS to preserve them during copy, save, sync and backup. You can read the macOS 26 version of those source files in Apple’s Open Source GitHub.

FileProvider

For the next decade or so, iCloud Drive mostly respected those behaviours, although without documentation it all appeared puzzling until you read the copyfile source. Then Apple decided to modernise it by implementing its FileProvider framework, a major architectural change for the better. Although the framework is intended to be common to all cloud storage services, there remains ample scope for iCloud Drive to offer enhancements.

Current FileProvider documentation for developers states:
“The extended file attributes are part of the item’s metadata. The system sets extended attributes on dataless files, and preserves them on files that it renders dataless. The system decides which attributes to sync. To sync an attribute, it calls the xattr_name_with_flags(_:_:) method and passes the XATTR_FLAG_SYNCABLE flag. Some older attributes are also synced.”

While FileProvider appears intended to conform to the xattr flag scheme, there’s no mention of the tables of default flags listed in the copyfile source code.

Implementation

Last week I set out to test and document how well iCloud Drive manages metadata, following the xattr flag system and copying up all those invaluable com.apple.metadata:* xattrs, only to discover it doesn’t any more. Of Apple’s many standard xattrs, the only ones I found that synced reliably over iCloud Drive in macOS 26.4.1 were:

• com.apple.metadata:_kMDItemUserTags (Finder Tag)
• com.apple.lastuseddate#PS
• com.apple.quarantine
• com.apple.TextEncoding

The good news is that iCloud Drive through FileProvider does respect the S flag, but only where it’s explicit, rather than being set in that table of defaults. For those of us who have our own xattr types, such as those used for integrity checking by Dintch, Fintch and cintch, can still rely on iCloud Drive to sync those, provided they bear that S flag.

The bad news is that none of the most popular metadata-bearing xattrs are synced, apart from Finder Tags. All those com.apple.metadata:kMDItem* xattrs are blocked, as FileProvider doesn’t recognise them as having their default PS flags.

Workarounds

I have since looked at two workarounds, explicitly adding the S flag to those types that should be accorded it by default, and changing the xattr names from com.apple.metadata:kMDItem* to com.apple.metadata:_kMDItem*.

Adding xattrs like com.apple.metadata:kMDItemKeywords#S with an explicit S flag does ensure FileProvider syncs those xattrs. However, as neither Spotlight indexing nor the Finder appear to understand that flag isn’t really part of the type name, those preserved xattrs are of no use: they aren’t recognised by Spotlight for indexing, nor are they displayed in the Finder’s Get Info dialog or Preview pane.

Inserting an underscore into the xattr’s name was even worse, as it didn’t lead to their preservation, and was ignored by Spotlight indexing and the Finder.

This raises another interesting issue, in that there doesn’t appear to be a way to extend Spotlight indexing to encompass additional xattr types. There are extensive third-party type libraries, such as org.openmetainfo:* from Tom Andersen of Ironic Software and OpenMeta. But those appear to require their own indexing, search and presentation support.

Error

When I first realised the impact on metadata in iCloud Drive, I assumed this arose because the engineers implementing FileProvider, or those porting iCloud Drive to use that framework, had’t been aware of the xattr flag system and its primary purpose. But if that had been true, they couldn’t have respected explicit use of the S flag. Thus, I’m left with two plausible explanations:

• Apple’s FileProvider/iCloud Drive engineers are unaware of the system defaults table in copyfile, so assumed that com.apple.metadata:* xattrs weren’t intended to be preserved when syncing.
• Apple decided to end default sync support for com.apple.metadata:* xattrs in iCloud Drive.

The second of those is even more erroneous than the first, as it reduces iCloud Drive support for metadata to a level common with third-party cloud providers. In this respect, users will see no difference from the behaviour of Dropbox or Microsoft OneDrive, which isn’t the marketing choice I’d have expected from Apple.

Conclusion

iCloud Drive no longer syncs much metadata stored in xattrs, in particular that stored in com.apple.metadata:* xattrs, apart from Finder Tags. There is no workaround, and unless Apple restores that feature, it limits the use of iCloud Drive with Macs.

QuickLook, or Quick Look, is the part of macOS responsible for generating custom Thumbnails and Previews of items in the Finder and elsewhere. Although it was only introduced in 2007, with Mac OS X 10.5 Leopard, its origins go back to 1988-91 when image Thumbnails could be saved in a file’s ICN# resource. A similar system arrived in Mac OS X, and was replaced by the first version of QuickLook in 2007, which has recently undergone revision, over the period 2019-25.

Resource-based Thumbnails in Classic Mac OS were relatively straightforward. Each type of file had its own icon, an association made in the hidden Desktop database. Image and video files often overrode that default by providing their own Thumbnail image as a resource, and had to update those when the file’s data was changed. Amazingly that’s still supported in modern macOS 35 years later.

QuickLook took on the task of generating Thumbnail images, and added larger Previews in which the whole document can be inspected without opening it in an app. This came with built-in Thumbnail and Preview generation for a wide range of common document types, extending to QuickTime media including audio and video. Apps are different, though, as they use icon image (icns) files stored in their bundle’s Resources folder, harking back to Classic icon resources.

Display of Thumbnails used the QuickLook framework documented here. This enabled third-parties to extend coverage to their own document types using QuickLook generators with the extension qlgenerator. Initially, they were installed into /Library/QuickLook from each app bundle.

Unlike Spotlight indexes and document versions, QuickLook stores all its files in the current Data volume, rather than locally on individual volumes. Normally, when QuickLook generated a Thumbnail or Preview, that was stored in its cache database kept in a temporary directory in the path C/com.apple.QuickLook.thumbnailcache/. Those could give revealing insights into images and other documents accessed recently, and Wojciech Regula and Patrick Wardle discovered that, in High Sierra and earlier, it was easy for malicious software to examine that cache. Apple addressed that in macOS 10.14 Mojave by making that cache completely inaccessible.

In-memory caching of Thumbnails has also proved controversial in more recent versions of macOS. To deliver smooth scrolling of Thumbnails in the Finder’s Gallery views in particular, the Finder has taken to caching them in memory for up to two days, sometimes using several GB in the process.

I described how QuickLook Thumbnails worked in early 2019, in the days before the SSV.

When you selected a document in the Finder, a dialog, or somewhere else where you expect its icon to be shown, the Finder passed details of the document path and its type (UTI) to IconServices, to fetch the appropriate icon. This called on its main service, iconservicesd in /System/Library/CoreServices, to check its icon cache.

Although the main icon store is locked away in /Library/Caches/com.apple.iconservices.store, there was additional data in a folder on a path based on /private/var/folders/…/C/com.apple.iconservices, where … is an unreadable alphanumeric name. For icons used in the Dock, their cache was at /private/var/folders/…/C/com.apple.dock.iconcache. If the icon should be replaced by a QuickLook Thumbnail, such as in a Finder column view, QuickLook is asked to provide that thumbnail. That in turn may be cached in its protected cache at /private/var/folders/…/C/com.apple.QuickLook.thumbnailcache.

QuickLook then relied on there being an appropriate qlgenerator to create a thumbnail of that document type; if the qlgenerator was flawed or could’t cope with the document’s contents, that could easily fall over. For example, if you renamed a text file with a .jpeg extension so that macOS considered it was a JPEG image, the bundled qlgenerator might have simply resulted in the display of a busy spinner, rather than resolving to a generic JPEG document icon. IconServices should then deliver the appropriate icon back to the Finder to display it.

In macOS 10.15 Catalina (2019), Apple started replacing this system with a new framework named QuickLook Thumbnailing, documented here. That replaces qlgenerators with QuickLook preview extensions, in particular Thumbnail Extensions, as explained to developers at WWDC in 2019.

macOS 15.0 Sequoia finally removed support for third-party qlgenerators, resulting in the unfortunate loss of custom Thumbnails and Previews for document types of apps that are still reliant on qlgenerators, and haven’t yet got round to providing equivalent app extensions.

When you now select a file in a view which should result in the display of its thumbnail in the Preview pane in that window, the Finder requests it from the QuickLookThumbnailingDaemon. That queues the request until the daemon can look for the image in its memory cache. If it can’t find it there it then looks in the disk cache, first at low quality 20 x 20 icon mode. If it still can’t find it, it queues a request for a fresh thumbnail to be generated. That uses the file data together with the appropriate code to create a Thumbnail, which is then returned and cached.

There’s at least one exception to this, the directory at ~/Library/Messages/Attachments/. For files inside that, and any others for which a Thumbnail can’t be generated, a generic icon is returned as the “most representative thumbnail”.

While third parties have been replacing their old qlgenerators with modern Thumbnail and Preview extensions (appexes), macOS still provides its standard qlgenerators in /System/Library/QuickLook. Third party appexes normally come in PlugIns folders in app bundles. Mints can provide a full listing of those installed. If a document type isn’t being thumbnailed as you’d expect, the first task is to discover its type as a UTI. You can then look up which qlgenerator or appex should be responsible for generating Thumbnails or Previews of that document type using Mints. By far the most common cause at present is an old third-party qlgenerator that hasn’t been replaced by an appex.

One of the design features of macOS is that a file’s metadata can be stored separately from that file’s data. This is normally achieved by extended attributes, xattrs, and to aid that there’s a rich and extendable range of them. This article explains what you can and can’t do with them, as of macOS 26.4.1.

More generally, most metadata are stored within a file’s data, to accommodate operating systems and file systems that don’t have such rich features. Most image formats, for example, incorporate standard collections of metadata such as EXIF information, which are saved with the image data. PDF and Word documents have similar features. These have the disadvantage that changing the metadata results in the file data being altered, and that makes it difficult to track and to guarantee the data’s integrity. This can result in damage or corruption to the data in a PDF file during editing of comment metadata, for example. When possible it’s far better to separate metadata.

Distinguishing between data and metadata can also be tricky at times. This is easiest with non-verbal data like images and audio, where text is clearly separate from data, but it can appear more arbitrary with written documents. Some content such as copyright information or an index is universally accepted as metadata, but abstracts and appendixes may vary. Some types of document, such as official standards, draw explicit distinctions, using qualifiers like normative and informative, to assist.

Finder Comments and Tags

These are the two standard types of metadata currently best supported in macOS, both being readily accessible in the Finder and applicable to any file or folder.

The main problem with Finder Comments is that they are primarily stored separately in the hidden .DS_Store file in the same directory as the item, although a secondary copy is written to a xattr attached to that file/folder. They’re easily accessed in the Finder’s Get Info dialog, and can be shown in List view windows, although that doesn’t work for multi-line comments. On balance, their strange storage makes them fragile and unsuitable for many uses.

Finder Tags are stored properly in a xattr, and are most widely distinguished by the coloured tag displayed. Although they can be repurposed to store text, their main value remains in categorisation. There’s a practical limit of 20-25 characters before their text label is cropped in most views, and labels for multiple items can only be shown in the Finder’s List view layout. For the majority, they are best used for allocating items to a limited number of categories, distinguished foremost by their tag colour, and aren’t suitable for more substantial text like even a brief summary.

Properties

To be generally suitable for storing text metadata for a file or folder in macOS, these should:

• be attached to the file or folder as a xattr;
• be capable of storing and displaying up to 3,804 bytes of UTF-8 text, the upper limit of data stored alongside the xattr;
• use xattr flags to control their persistence;
• be indexed by Spotlight so their contents can be searched;
• be preserved in iCloud Drive, and when copied to a different volume;
• be displayed and edited easily, ideally in the Finder, without the need for third-party software.

Which xattrs?

Of the dozens of xattrs available, I’m aware of just three that come closest to meeting all those requirements:

• com.apple.metadata:kMDItemComment, known in Spotlight search menu as Comment, and different from Spotlight Comment, which is synonymous with Finder Comment;
• com.apple.metadata:kMDItemKeywords, Spotlight Keywords;
• com.apple.metadata:kMDItemSubject, Spotlight Subject.

These are sufficiently persistent as to be preserved in iCloud Drive, and when transferred between Macs using AirDrop. Although they can be displayed in the Finder, they each require third-party software for creation and management. As explained below, this doesn’t apply to image files, which are expected to store their metadata in EXIF information within the file, and not in xattrs.

Management

All three can be created and managed using my free Metamer, as well as with the more extensive features of xattred.

Metamer is a lightweight drag-and-drop utility to create, edit and view many different types of xattr, including the three recommended. It uses a Combo box offering 16 of the most commonly used xattrs, and you can enter the full name of any other if you need. Although it can be used to edit multi-line text, it’s designed to work best with single lines.

xattred is a general xattr editor with more extensive capabilities, and ideal for checking all the xattrs attached to a file or folder. It doesn’t offer the conveniences of Metamer, though.

Display

Each of these three xattrs is displayed in the More Info section of the Get Info dialog, and depending on settings, they can also be shown in the Finder’s preview pane when enabled in Preview Options for that file type. The latter is explained in more detail here, and can appear counter-intuitive at times. However, they can only be added and displayed for supported file types. For example, JPEG and PNG image files can’t display these three xattrs in Get Info dialogs or in the preview pane, but PDF, RTF, text and many other file types can.

None of the three can be listed for multiple files in any of the Finder’s view layouts.

Spotlight

All three are available in the list of search terms available in the Other item at the foot of the search term menu in a Finder Find window, as listed above.

But

When researching this article, I discovered some odd behaviours that render some xattrs both invisible and undiscoverable by Spotlight search. I hope to describe those fully tomorrow if I can get my head around them.

Finder tags are a simple and accessible way of categorising files and folders by attaching one or more of seven colours to them, together with a text label. This article explains how they work, and how to get the best from them.

Tag metadata

Finder tags are stored in extended attributes of type com.apple.metadata:_kMDItemUserTags. They consist of a binary property list containing a little UTF-8 text. This is an array of strings, each containing a tag name, followed by the newline character, followed by the colour number (0-7). The array can be empty, which usually indicates a tag had been attached, but has now been removed.

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. As the user can assign (almost) arbitrary text to labels, those could equally be Urgent\n6, or Important\n7 Project\n2. When in a location indexed by Spotlight, the text content prior to the newline character (excluding the digit) in each tag is indexed.

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

Tagging

Tags are easily added to a file or folder in the Finder by selecting the item and using the command in the contextual menu. The menu lists the seven favourite tags, as selected in the Finder’s settings, by colour.

A separate command opens a floating window offering all tags instead, giving access to others in addition to the seven favourites.

Tags are removed from items using the same tools, either to remove one of the seven favourite tags, or any other that has been attached.

Once attached to a file or folder, the colours of its tags are displayed in the Name section of each type of Finder window. List view can be set to display the text label as well, although that’s not available in other window types. In macOS Tahoe, tagged folders are also coloured according to the last of the tags attached to them, when that option is enabled in the Finder’s settings.

Tags are widely supported in the Finder, macOS tools, and apps. When you show Tags in the Finder’s sidebar, you can view items with only a specific tag by selecting that tag in the sidebar. The same feature works in file Open and Save dialogs in all apps using the standard macOS dialog too. You can further refine tag-based listings by opting to sort those files in date or other orders, and you can group by tags as well.

Editing and management

Tags and their text labels are managed in the Finder’s settings, in the Tags tool.

This allows you to add and remove tags from the main list, to edit the label of each (either in the same way you rename files in the Finder, or using the contextual menu), to delete a tag, and to set which tags appear in the list of seven favourites at the foot. If you customise one of the standard tags by changing its name, say from Red to Urgent, then the Finder automatically changes all items marked with that tag to show that new label.

Similarly, deleting an existing tag from this list removes it and its label from all files and folders tagged with them, throughout that Mac’s storage. This behaviour can sometimes catch users unaware of those extensive consequences.

Each tag and label remains associated with that file or folder: when you copy it across to another Mac, the tag remains attached, and on that second system should continue to show the same colour and label. This also applies to any custom tags you add. The important exception to this is if the item is moved using a method that doesn’t preserve its extended attributes, which occurs on some file systems such as NFS, and when using some command line tools. Some backup methods may also not preserve extended attributes, and will strip all your tags; Time Machine preserves them all.

Categories and labels

There are only seven different tag colours, and although many different labels can be associated with each colour, in practice Finder tags work best when tags and labels are matched one-to-one. Note that you can’t associate two different coloured tags with the same label.

Tagging is simplest when each colour only has a single label associated with it, as colours and labels are then fully interchangeable. Labels can also work well when used to qualify categories, for example using red tags for those tasks due this week, with text specifying the day. Broadening the range of labels for a given tag can quickly lead to confusion: imagine the consequences of using a red tag with emails that are labelled Important, and those marked as Junk.

For example, if you want to classify your photos into no more than seven categories, such as social, travel, parties, and so on, they should work well with tags. If you want to add the names of people in each image, or their locations, then tags are likely to be the wrong type of metadata for that. Another example is tagging projects: if you need no more than seven different project tags, then Finder tags should serve well. If you need a dozen or more, then they’ll quickly prove inadequate.

Labels aren’t intended to contain longer text, as they’re not displayed in a way that would make that easy to read. If you want to attach structured or free text to files and folders, use other extended attributes including Keywords, Comment (not Finder comment, though), Description, Subject and Information. Although these are also indexed by Spotlight and can be searched for, there is still no option to display them in Finder windows.

Spotlight search

Finder tags can also be used as a criterion in Spotlight searches, although those are based not on the tag colour but its label, such as Important for a red tag labelled Important. You’ll need to add the Tags item to the Finder’s list of search criteria before you can use it to find items in the Finder’s Find window.

Happy tagging!

Parts of macOS go back a long way, and have scars to prove it. Among those are Finder comments: text you can easily add to a file’s metadata in the Finder’s Get Info dialog. Like all good metadata, it’s also searchable in Spotlight, so can be used to organise and categorise your documents. However, there are some catches that can make that unreliable.

Finder comment

To see what I mean, you’ll need an app like my free Metamer, a simple metadata editor, or xattred, to display extended attributes. Pick an old file you can sacrifice for this purpose. Select it in the Finder, and Get Info for it. In the Comments section, type in a comment.

Open that file in Metamer, and select the FinderComment item in its combo box menu.

Your freshly written Finder Comment has already been added as an extended attribute.

Open the file in xattred, and you’ll see that text as a String in a property list for that extended attribute.

Now change the name of that file, perhaps by adding a short suffix. Get Info and the Finder Comment is still there.

Look at the extended attribute using Metamer or xattred, and you’ll see that the String in the property list has been deleted, and the extended attribute no longer contains the text still displayed in the Get Info dialog.

This is because

• the primary copy of the Finder Comment goes into the hidden .DS_Store file in the same folder as the document, and that’s the one used by the Finder;
• a secondary copy is saved in a xattr of type com.apple.metadata:kMDItemFinderComment for the file, which the Finder knows nothing about.

You can experience other strange effects from this dissociation between those two copies, and their different behaviours. As a result I don’t recommend use of Finder comments, because of their unreliability.

Steganography

Finder comments and other metadata provide a scheme for steganography in macOS. This was first used by Wdef, one of the original viruses that affected Classic Mac OS in about 1990, and was resurrected 30 years later in 2020, when Phil Stokes of Sentinel Labs reported a Bundlore variant abusing the Resource fork, then as now an extended attribute of type com.apple.ResourceFork.

Just recently, William Charles Gibson and Ryan Conry of Cisco Talos have described how a similar technique could be used “to stage payloads in a way that evades static file analysis”. They propose using a payload script, encoded using Base64, and written to Finder comment metadata.

Writing the malicious Finder comment is simple to achieve using the AppleScript code
set comment of newFile to "$PAYLOAD"
and retrieval, decoding and execution by the command
mdls -name kMDItemFinderComment -raw ~/Desktop/remote_test.txt | base64 -D | bash
also run from within AppleScript.

There are three disadvantages in using a Finder comment for this purpose, its fragility as shown above, its visibility to the user in the Finder’s Get Info dialog, and reliance on Spotlight indexing and search. If you want to use file metadata for steganography, then you’re better off using an extended attribute directly, accessing it with the xattr command tool, which is robust, remains with the file rather than in a hidden .DS_Store file, and doesn’t need to be indexed by Spotlight or found using mdls.

That also gives you a wider choice of extended attribute. If traceability isn’t important, a custom xattr can be used with the PS flags to ensure its persistence in copies, saves, syncs and backups. There’s a long list of those supported in macOS, including kMDItemProjects, which is stored in the com.apple.metadata:kMDItemProjects xattr and treated as having PS flags, and most importantly isn’t exposed to the user in the Finder’s Get Info dialog.

At this stage you might want to check how thoroughly your malware protection checks extended attributes for malicious content. As a rough guess, I suspect the answer is not at all.

If you’ve installed Apple’s new Creator Studio versions of what used to be its iWork apps, I’m sure you noticed something odd in your Applications folder. For there, side by side, are apps with exactly the same names, two Keynote.apps, two Numbers.apps, and two Pages.apps. This article explains the trickery that went into that.

We take it for granted that what we see in the Finder is truthful, despite obvious trickery like hidden folders, and iCloud Drive which doesn’t really exist at all. When it comes to bundles like applications, the Finder doesn’t actually show the true folder name, but the bundle name set in that bundle’s Info.plist.

You can get an inkling of what’s going on by selecting the two Pages apps and opening Get Info on each.

The old Pages.app looks straight, giving its Name & Extension as Pages.app as you’d expect.

But the Name & Extension given for the new Pages.app turns out to be Pages Creator Studio.app, and that’s the real name of its app folder.

Check both using my free utility Precize and you’ll see they are completely different, with their own inode numbers and paths. Drag them into Terminal and that shows their true names in the file system, of Pages.app (old) and Pages Creator Studio.app (new).

If you have a property list or text editor handy, copy the Info.plist from inside each app bundle and inspect them side by side.

The old Pages app is still playing this straight:
CFBundleDisplayName = Pages
CFBundleName = Pages
CFBundleIdentifier = com.apple.iWork.Pages

By comparison, the new app is up to no good:
CFBundleAlternateNames = Pages
CFBundleDisplayName = Pages Creator Studio
CFBundleName = Pages
CFBundleIdentifier = com.apple.Pages

Apple provides further details of the contents of Info.plist in this developer article.

There’s a great deal more to accomplishing this with finesse as Apple has done here. Other locations in the app such as its About window and menus also need tweaking to ensure that nowhere breathes a word about the trick that has been pulled. And just to add a bit of spice, apps still using AppKit are quite different from those now using SwiftUI.

My only remaining question is why Apple would want to give the two apps identical names. The primary purpose of setting the CFBundleDisplayName is to accommodate better to the limited display area on devices. An app that has a long full name, like The Time Machine Mechanic, obviously needs to be shortened, and ellipses are a clumsy solution. By giving the app developer the opportunity to display something shorter it makes our iPhones look much neater.

Although it’s a clever trick to pull in macOS, I suspect it’s going to confuse more than it amazes.

Many thanks to Joe who asked this question.