It’s a well-known fact that you can’t have two items, let alone apps, with the same name in the same folder. On this occasion, there’s no sleight of Unicode, no spoofing with lookalike characters: those really are two separate copies of TextEdit shown by the Finder in the same Applications folder. And it’s something you can do in a few seconds, in which you can come worryingly close to what could have been a serious security vulnerability.

To do this, you need to be running Catalina. Open the main Applications folder in the Finder, locate TextEdit, Chess, or another of the apps which Apple bundles with macOS – which doesn’t include Safari, of course – and duplicate it using the menu command or Command-D shortcut. You should then have a copy of the app named, for example, TextEdit copy.app. Edit its name to remove the copy, making it the same as the original. Finder doesn’t refuse this, and happily shows you both apps with identical names side by side.

The reason, of course, is that the Finder’s fooling you again: those two apps are actually in different folders, because of Catalina’s read-only System volume. The original is on that System volume, in the folder /System/Applications, whilst the copy you made (which can’t be written to the same folder on the System volume because it’s read only) is actually on the Data volume, in what appears to be the top-level Applications folder there. Although the Finder pretends that it’s in /Applications, its actual path is more like /System/Volumes/Macintosh HD/Applications, which a firmlink brings back to /Applications, merging in the read-only contents of /System/Applications.

So what’s to stop malicious software from using this to trick you into running a specially-crafted version of TextEdit, or another of the apps which are bundled in macOS? Provided that the bogus version of the app on your Data volume doesn’t get put into quarantine, surely macOS won’t put it through Gatekeeper’s full first run check when you open the bogus app, and it’s likely to slip past any more basic signature check, isn’t it?

Thankfully, there are several things working in our favour, and against the malware author. Most importantly, when you do try to open this writeable copy of the bundled app, the security system recognises that it’s being launched from a new path, and puts it through a fuller signature check. Even a small change to the underlying app should be picked up by this, making it much harder for the malware author to slip past the checks. But you can still put an alien PDF file in its Resources folder, for instance, without that causing any problems.

Before you argue that the Finder should prevent this from happening, remember that the Applications folder is by no means the only place in the boot Volume Group that this could happen. In other locations, this may need to be acceptable behaviour, and there’s no conflict with the fundamental requirement that every file and folder has a unique path, as it’s only the Finder’s illusion which makes this appear to occur.

It’s also worth being aware of one side-effect: when you do this with an app like TextEdit, which is likely to be the default app for opening Rich and plain text documents, macOS – or more precisely Launch Services – should continue to use the copy of the app on your System volume when opening a document by double-clicking it. Normally it determines which copy to use by its build number, preferring the most recent, so could be more conflicted if the duplicate were to have a higher build number. But that doesn’t come into play when you’re just making duplicates.

Now that you’re done with your second copy of TextEdit, you don’t have to worry about throwing away the correct one. macOS won’t let you trash the original from the System volume, as it’s read only and protected by SIP, so you can only remove the copy you just made.