It’s very unusual to catch a Mac app going out of its way to destroy your data, but recently Chris Hamady (@chamady, via @lapcatsoftware) drew attention to a glaring example in TextEdit. Not only that, but it’s been doing this since Yosemite back in 2014, and persists in TextEdit version 1.14 in Mojave 10.14.4.

Demonstrating this appalling behaviour is simple with an HTML file which you can afford to lose, because with TextEdit that’s guaranteed data loss. Open the HTML file, and use the Make Plain Text command in its Format menu. You’ll next see a dialog which warns you that proceeding will replace your original HTML file with that plain text conversion, losing all the additional markup in the original.

If you Cancel here, nothing untoward will happen. In older versions of macOS, there’s a second dialog which appears to offer a reprieve, and allows you to cancel this irreversible loss of data. Unfortunately, that dialog is not telling you the truth: if you Cancel there, it’s already too late and your original HTML has gone for good. Mojave doesn’t offer that second false chance, and if you click on OK in the first dialog, your markup has already gone.

The real bug is in older macOS, where that second dialog doesn’t do what it claims. But the whole behaviour is unnecessary: TextEdit is going out of its way to delete your original HTML document when there’s no need at all. It does that because whoever implemented this behaviour didn’t understand macOS (or iOS for that matter).

Not only did that engineer not understand the operating system they were developing for, but whoever signed off on that behaviour failed to check it. Ever since then, for the past nearly five years, no one in Apple has seen fit to do anything about this.

So why does TextEdit quite needlessly delete the original HTML file in order to save a plain text version? Even the most neophyte Mac user quickly comes to understand than macOS and its file systems are perfectly capable of thisfile.txt and thisfile.html peacefully co-existing in the same folder. Why can’t TextEdit allow you to do so?

To discover the reasoning behind this, I looked at how this works in a TextEdit replacement, my free DelightEd, which relies on Apple’s Cocoa architecture to handle this. The confounding factor here is that both TextEdit and DelightEd use the new-style autosave architecture, although both can import and save a similar range of file types. Although this can be a pain in certain respects, it brings with it both automatic saving of documents and, most valuably, macOS versions.

DelightEd adopts the long-standing approach to ‘converting’ between formats such as HTML and plain text: it does so when you save a document as a different type. It doesn’t need any special menu command to perform conversion. So in this case, all you have to do is open the HTML document, use the Save command, and select the Plain Text option. Cocoa even adds an option when you’ve changed the document, a checkbox which allows you to save those changes to both the original and the new document. Instead of trashing the old in favour of the new, DelightEd does what the user expects and Cocoa facilitates – it creates a new file alongside the original.

For many years, Apple used TextEdit as exemplary code for macOS developers to see how it’s done. The last time it did this was seven years ago, in early 2012, since when I can only presume that TextEdit has gone steadily downhill and is now too embarrassing to release in source form. Like so many other standard tools in macOS, TextEdit is another festering sore on the rump of Apple’s engineering indolence.