Apple has never been short of Big Ideas. In the days of Classic Mac OS, they seemed to stream out so quickly that developers were left gasping for breath – QuickDraw, Object Pascal, MacApp, QuickTime and HyperCard to mention just a few. Although all of those have now had their day, their influence on what are now macOS and iOS has been great.

Big Ideas aren’t always easy to spot at the time. Some, like OpenDoc, prove as ephemeral as mayflies, and we’ll always wonder what might have happened if they had had a chance to blossom for a bit longer. Some live on, deeper inside macOS, shunning the limelight but still doing a vital job – like UTIs.

No one seems to know when Apple first came up with the idea of Uniform Type Identifiers (UTIs), but they were first seeded in 2004, as Mac OS X 10.4 Tiger was being developed. Like some of the best Big Ideas, they emerged from a problem, a clash of cultures between Classic Mac OS and Unix.

Classic Mac OS was one of the first widely-used operating systems which allowed the user to name documents however they liked, and which let you open a document, rather than tell an app to open a file. Instead of relying on filename extensions, as did Unix and MS-DOS, every file had type and creator codes which Mac OS co-ordinated with information about apps to determine what to do to open any given document.

Mac OS X had to support both systems for associating file types with apps, and faced another problem: how to associate internet MIME types with file types. Apple’s solution was the Big Idea of a taxonomic system which could, in theory at least, be used to classify anything in the universe: the Uniform Type Identifier.

Faced with a document from a Classic Mac, with a type code (now known as the OSType) of TEXT or ttro, macOS would recognise that as having the UTI type of com.apple.traditional-mac-plain-text. You’re unlikely to have an app specially assigned to that document type, so macOS looks at the next more general type up the UTI hierarchy, public.plain-text. This is associated with filename extensions .txt and .text, and the MIME type text/plain, and should open that document in your default text editor.

Starting from less than a dozen fundamental UTIs like public.item, public.content, and public.executable, Apple built a tree which now includes public.swift-source for Swift source code, com.apple.automator-workflow for Automator workflows, and com.apple.iwork.keynote.sffkey for Keynote presentations.

They’re used by LaunchServices so that the Finder can associate file types with editing apps, by QuickLook to determine which previewer to use to build thumbnails and previews of documents, and the Clipboard (‘Pasteboard’ to developers) to decide what types of content can be copied and pasted where. The moment that you start writing apps that work with documents, you’ll come across UTIs and need to know how to use them.

Swift is another of Apple’s flourishing Big Ideas, and using it in Playgrounds to learn to code is another. The “Everyone Can Code” initiative is a fine demonstration of Big Ideas starting to pay off in Big Ways. But there’s a lot more to coding than Swift Playgrounds: once you’ve moved on from the basic lessons, you’ll hit concepts like UTIs, which need a bit of explanation, and some key reference material.

When you turn to what Apple provides, there’s a UTI Overview which starts with the warning that This document is no longer being updated, and ends with the admission that it was last properly revised in 2009. The official table of system-declared UTIs was also created in 2009, has not been updated since, and is now incorrect in several respects.

Of course, there’s a much better answer: UTIs are essentially self-documenting. There should be a simple tool which can list all the UTIs in use in your installed copy of macOS, and provide a clear picture of their hierarchy. Only, as far as I can discover, there isn’t.

In reality, when you’re learning to develop apps which work with documents, working with UTIs is like trying to pin the tail on a donkey while wearing a blindfold. Making progress depends on inspired searching, guesswork, and trial and error.

Nor is this just a problem for developers. Understanding how UTIs work, and how they can go wrong, is essential if you are going to solve user problems. I recently dealt with a situation in which an ordinary folder had somehow been transformed into a Photos library, for example. Understanding why and how these things happen is fundamental to discovering their solution.

Big Ideas need Big Support, which means Big Documentation and Big Tools. For UTIs, at least, they are almost completely lacking. Without them, our bright new coders will become disenchanted and look for something that’s better supported. And who can blame them?