Inside Snow Leopard's UTI: Apple fixes the Creator CodeSnow Leopard's abandonment of Creator Code metadata, used to open a file with its creating application, has some users are worried that Apple has killed off a core Mac-centric feature. Instead, Apple has invented a superior alternative for the old Creator Code in order to support a variety of new features. Here's why, and what the new Uniform Type Identifiers offer.
What is a Creator Code?
Back in the early 80s, Apple developed a variety of unique conventions to make the Macintosh intuitively easy to use, almost to a magical extent. One example pertains to invisible file metadata that helped the system identify documents using Type and Creator Codes.
Each file was tagged with both a Type and a Creator, allowing the system to distinguish between applications that could open a file and the default application that should open the file. The Finder could also use this invisibly associated file metadata to present custom file icons for different files of the same type but created by different applications, such as two JPEGs, one saved by Graphic Converter and the other by Photoshop.
The Finder maintained simple associations between applications and files, so that any document created in Word would open automatically with Word, and each of several different text documents would each open with the application that was used to create it. In the days when users had a few simple, monolithic applications, this Type/Creator convention made sense.
On DOS and Windows, the operating system could only determine how to open a file based on its file type extension, which was explicitly part of the the file name: myfile.doc. DOS and Windows were helpless to offer the user any assistance in knowing what application originally created a given file, unless the file were saved to a proprietary format that only one app could possibly open. In that sense, Mac Creator Codes encouraged the use of common, interoperable file types while still associating certain files with a specific app.
Leaving the Mac island
The Creator Code convention worked well until documents began moving to and from other platforms, such as being saved to a DOS disk or a Unix-based file server, or via email or the web. DOS and Unix ignored the Mac metadata, so they didn't know how to open the files received from Mac users, as those files typically lacked the simple file extension that those other systems required to interpret the file's type.
Additionally, since those platforms also scrubbed away the Mac metadata, files copied to and from a non-Mac savvy platform couldn't be correctly identified or opened on the Mac anymore either. With Apple's magic removed, the files just sat there with blank generic icons, and the Finder acted just as helpless with them as Windows. The problem for Mac users was eventually solved by packaging the Creator Code information to withstand transport on a non-HFS formatted disk. That didn't help Mac users who needed to send their files to users on other platforms however.
The common solution to that issue came to be to assign Mac files redundant information: both Type and Creator codes as well as a file extension. On NeXT and later Windows, files were given file extensions only, as there was no underlying file system support for Mac-style metadata for Unix or DOS. NeXT's impact on Apple was particularly evident in the shift away from Creator Codes and toward file extensions.
Old time Mac users often looked at file extensions as an ugly and unnecessary feature required only to allow Macs to interoperate with the filthy masses. So, when Mac OS X arrived with support for the old Mac metadata but with new guidelines from Apple mandating that developers also use NeXT-style file extensions to express type, there was consternation that the Mac was losing the things that made it special.
Complaining about the end of the road for Creator Codes fit in with unrest about other changes afoot at Apple, such as the loss of the Spacial Finder (the idea that you shouldn't be able to view a folder in the Finder in multiple views at once; that files should be locked into the view you last saved and stay there until you modify it).
Why Creator Codes Died
However, Apple didn't schedule a deprecation of Creator Codes just for fun, or just to be lazy, or just to fit in with lowest common denominator operating systems. Type and Creator Codes simply weren't good enough to support new OS features Apple had on the drawing board. Rather than trying to get by with doing less, Apple was set on doing more, and Creator Codes weren't up to the task.
There are lots of places where the operating system needs to handle advanced data type management which transcends the basic file Type and Creator Code system developed for identifying documents on the original Macintosh nearly 30 years ago. The system must also do this in a way which remains compatible with the file type extensions in use on other platforms.
Type and Creator Codes each used four-character labels, limiting the potential for expansion. That was an improvement upon the DOS idea of 8.3 names, which truncated documents, executables, and JPEGs to cryptic, three letter .doc, .exe, and .jpg file extensions. However, creating a new Type or Creator Code required registering with Apple, because there was a finite number of expressive codes available between 0000 and ZZZZ.
Today, the app used to create a file is not necessarily the one that most users want to open it with; the Creator Code system didn't offer any simple way for users to modify the creator after the fact, either individually, collectively for a selection of files, or across all files of a given file type. The complexity of what users expect to do (and what kinds of data they are working with) in 2009 is vastly different than it was back in the early 80s when Apple conceptualized the rather simple Type and Creator Codes.
To support new kinds of features, Apple invented a flexible new system for expressing file and creator information in a system called Uniform Type Identifiers. The idea of rich file typing wasn't entirely unique; the BeOS began using MIME types as its mechanism for expanding upon the concept of File Type and Creator Codes during the 90s. However, MIME had its own issues.
MIME types are used by web servers and in email to express the type of file being served or attached. For example, a web server might identify a graphic as "image/jpeg" in addition to the file's .jpg or .jpeg file type extension. MIME also allows developers to make up their own types, either by registering a specific name with the IANA (the root DNS naming authority) or making up ad hoc names, an improvement upon Apple's registered Type and Creator Codes.
The BeOS copied a page from the web browser, which allowed users to define which helper app should be used to open a file of a given MIME type. If it encountered a specialized MIME type that it didn't recognize (such as "text/xml"), it could try opening it with the program designated to open plain text files. This "type/subtype" system offered a two bucket approach to defining file type, allowing specialized files to be opened by more general apps if necessary.
However, MIME was originally created just as simple way to push international characters and binary attachments through the Internet's SMTP email system (which only understands plain ASCII text). MIME only offers simplistic, rudimentary support for identifying the kind of data being transmitted. Apple wanted a much more rich and robust system for detailing more than just the basic document type of some binary data.
On page 2 of 3: Data typing beyond files, Introducing UTI.